[Unison-hackers] Multi-user, single UID ideas for Unison

[Greg Troxel]

nikp123 <nikp123 at e.email> writes:

> I was considering whether it is in scope of the Unison project to add
> anything relating to isolating folders for a SSH-ran server process
> for the purposes of protecting other users and preventing any
> potential data leaks.

Thanks for joining the list.  There are several hundred people here, and
my impression has been that fairly few subscribe to all github issues.

> So my use case relies on software that isn't able to authenticate and
> change file/directory UIDs depending on what user is authenticated
> such as FileBrowser (https://urldefense.com/v3/__https://github.com/filebrowser/filebrowser__;!!IBzWLUs!SmlCGFNv3bUvD5Vo2yzmlEWXrSucFSt4Pds0PfCMw3dRj1OyfSiKbQRKPLUAzdr-pDoOR-orVZ0T4hcFwkagRs0Y$ ).

You say "filebrowser can't" but that seems just like "unison can't" and
just as open to change.  It strikes me that currently filebrowser is
designed to be personal and you are using it outside of its design
assumptions.  Perhaps:

  You might run nextcloud instead (but not really sure how that would
  go as nextcloud wants you to use nextcloud interfaces and not
  manipulate the db).

  You might run one filebrowser process per user and use nginx reverse
  proxy to glue them into one https port with pathnames.  I don't
  understand why there can't be multiple.

Overall, it feels like trying to reinvent unix permissions within a
process (said in a very broad brush way, not trying to be fair).

> My solution (that I have proposed) would require Unison to prevent the
> user from reading outside of its launch directory, effectively
> preventing the user from being able to leak data from other users or
> the server itself.

One could think about chroot into the dir to be synced.  The problem
that then arises is that unison stores fp/ar files in ~/.unison, not
with the files being synced.  But perhaps that should change; I tend to
think that having control files near the data is better.  With that, it
might be possible for the server to chroot.

You mention "would need system files", but I don't know which files and
why?

> But I am not asking for any *particular* solution, I'm asking if the
> solution proposed here sounds sane or even practical. Yes, I do
> understand it's niche for almost all of you, but I'd like for Unison's
> syncing prowess to be useful outside of the server
> administrator/poweruser sphere. This was just one way of achieving
> that (albeit impractical for most people).

I find that unison plays well with multiple users in a timesharing
system, where the user has accounts on both sides.  I think you are
running into issues because the user has an account on the file server,
but you don't want them to have the equivalent of shell access, and are
thus wanting to have the unison process implement access controls.
Right now, it doesn't have a security function, so this is a huge
change.

All in all:

  1) I think if you want different users to be isolated from each other,
  they should have different uids, and you should resolve problems with
  software that can't serve multiple uids with that software.

  2) I think it would be a good thing to be able to, and perhaps by
  default to do so, change the location of the ar/fp files from
  ~/.unison to $SYNCROOT/.unison or someplace like that.  We have
    https://urldefense.com/v3/__https://github.com/bcpierce00/unison/issues/552__;!!IBzWLUs!SmlCGFNv3bUvD5Vo2yzmlEWXrSucFSt4Pds0PfCMw3dRj1OyfSiKbQRKPLUAzdr-pDoOR-orVZ0T4hcFwnYz5Bk2$ 
  That didn't talk about ar/fp-in-synced-dir but it does now.

  3) With (2) done, which I think is of general interest, then I think
  -- but I may be missing something -- that adding a single "chroot ."
  call to unison, after chdir to the sync dir -- with a bit of fixup for
  paths, might mostly do what you want, and that might well be simple
  enough and more broadly applicable as to be ok in terms of
  complexity/usefulness tradeoff.


It would be useful to hear if people agree that (2) would be a good
thing, and if anyone has other ideas for low-complexity ways for you to
get what you want.

Greg