Add ability to jail users within the current directory

[nikp123]

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:

1. We have a common server (Lets say a NAS or a Home Lab) that multiple users use.
2. We would like to use a software like FileBrowser in order to have a nice WebUI for accessing files that are synced to said server.
   2.1. This invalidates solutions that rely on multiple user accounts since FileBrowser assumes all files are stored using a single UID:GID pair. There is a workaround using bindfs but that creates other issues (more complexity and inotify stops working).
3. The authentication is done over SSH because that's the only thing Unison supports for authentication.

The issue is as follows:

1. A SSH user can be forced to run a unison -server as their command when they log into a server using a authorized_key trick, see unicloud. This way we ensure the user has no shell access on the sync server.
2. However, the user is still able to meddle with other files on the server, such as system files located in /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.

[gdt]

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.

[nikp123]

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.

[gdt]

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.

[nikp123]

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 ;)

[gdt]

I have moved this issue to the Feature Requests wiki page, as it seems unlikely to ever be implemented. But, the page collects such features so that they are not lost.