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

[Greg Troxel]

nikp123 <nikp123 at e.email> writes:

1> On 31. 10. 23. 00:08, Greg Troxel wrote:
>> It strikes me that currently filebrowser is
>> designed to be personal and you are using it outside of its design
>> assumptions.
> Maybe that is the case, but I was able to isolate users via their
> ability to specify paths for each user despite all files being store
> under one UID/GID pair. Maybe theirs was an afterthought and this
> wasn't? I don't know.

I can believe you can make it run, but it still seems strange for this
tool to ask that everything else on the system reinvent permissions.

> Even NextCloud that you mentioned afterwards also stores files in a
> single permission UID/GID pair on disk. (But NextCloud has other
> issues that make it unusable for me).

Yes, but nextcloud's design is that only the nextcloud server process
touches those files.

>> You mention "would need system files", but I don't know which files
>> and why?
>
> IIRC, when you chroot into a SSH session, it would act as a regular
> Linux chroot. The directory you're chroot-ing into would need to have
> ALL of the binaries (and their dependencies) you're planning to use
> already inside of it. This would be quite messy as you'd have to copy
> or link those at runtime which is just prone to too many
> failures. It'd be great if this wasn't the case and I just had a wrong
> understanding of it.

"chroot into an ssh session" is too imprecise to discuss.  chroot is a
system call, and there's a user process that executes it and then
another process.

unison only needs the unison binary and a few libs.  On my NetBSD system:

  /usr/pkg/bin//unison:
          -lutil.7 => /usr/lib/libutil.so.7
          -lc.12 => /usr/lib/libc.so.12
          -lm.0 => /usr/lib/libm.so.0
          -lpthread.1 => /usr/lib/libpthread.so.1

but I was suggesting that unison itself grow the ability to chroot once
it has changed cwd to the dir to be synced.  The process would be
loaded, and this should be easy to prototype, and then figure out if
that work and what else is needed.   Once ar/fp is moved.

>>    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.
> If this is possible, that would solve my problems. Because that
> *would* achieve the isolation that I'm looking for. But I remain
> doubtful for the reasons I wrote above.

I could certainly be missing something.