Open nikp123 opened 8 months ago
Please open a discussion about this on unison-hackers. This appears to be a niche requirement that is substantially due to an assumption that other software cannot be changed, and I evaluate reasonableness of features by assuming that all software is open source and that it is equally possible to add features to any of it (without knowing or caring if that is actually true).
When you do post, please explain whether you want this feature as part of a commercial activity, and what kind of budget (hours of a software engineer) you have approval to assign to this effort.
My apologies, I am a volunteer I have no-one behind this other than myself. This was more of a personal suggestion more than anything. I will be opening the thread on there to see if there's any interest or ideas about this.
That's fine- - if this is personal wish, that's totally fine. I just wanted to separate Free Software community from a company asking for free software engineering time. But basically, unless somebody wants to do this -- and we decide that the cost of an implementation being present in terms of codebase complexity, etc., is outweighed by utility over a non-tiny set of people, I think it is pretty unlikely this is going to happen. Basically unison is already too complicated. See you on the list.
That's fine- - if this is personal wish, that's totally fine. I just wanted to separate Free Software community from a company asking for free software engineering time. But basically, unless somebody wants to do this -- and we decide that the cost of an implementation being present in terms of codebase complexity, etc., is outweighed by utility over a non-tiny set of people, I think it is pretty unlikely this is going to happen. Basically unison is already too complicated. See you on the list.
Thanks, I hope I find some solution that works for me. In the worst case if nothing works out, I'll just use bindfs as a compromise. I do understand the need to keep the project from outgrowing its maintainers ability to keep it maintainable. For this I can only ask passively if anyones interested in this. Or perhaps if I find time to work on this myself (doubtful considering my current situation, but its still a realm of possibilites). But before any of that a discussion seems more appropriate before manhours are wasted.
Update: Post has been sent, hopefully I did not bother too many people with my request ;)
Sorry for posting an empty issue: GitHub's UX is awful (I'll complete this as I go)done :)Hello, I'd like to be able to jail users within a specific directory in Unison.
The user's setup is as follows:
The issue is as follows:
unison -server
as their command when they log into a server using aauthorized_key
trick, see unicloud. This way we ensure the user has no shell access on the sync server./usr
,/bin
,/etc
or other users/home
directories. We do not want that. 2.1. Jailing the users using a classical textbook SSH chroot jail would still require that we put system files into the users jail directory which is more effort and still doesn't eliminate the problem of properly hiding system files from the end user. The underlying servers operating system should be completely opaque to our user, no version leaks, no user folder leaks and such.My proposal is to allow Unison to hide all other files other than in the directory that its currently in and all of sub-directories of that same directory when running in server mode (aka. with
-server
) (over SSH only, because that's where it would make the most sense).This would eliminate the privacy risk and (potential) security risks involved with running unison on a single UID:GID pair, since the SSH server can be configured to run just unison and unison would not reveal any other files outside of the users home directory.
This would work due to the fact that SSH sets the sessions current directory to the HOME directory of the user that authenticated.
Apologies if this seems feature creep but I would really like for unison to be a valid one machine many users solution towards file sharing. Because as it stands its only good if you completely separate users and files into respective directories with their own permissions/owners, with potential leaks due to it being able to read files outside of its directory such as system files.
I have no prior knowledge of how unison reads files/directories so I can't be sure about how much work would there be needed in order to satisfy this change.
This could be implemented UX-wise as a
-current-dir-only
flag on top of the-server
flag.We could also have alternative approaches if the above solution seems like too much of a hack:
--sync-target=/somedirectory
- This would treat/somedirectory
as the root directory in the context of unison and wouldnt allow syncing anywhere outside of said directory.