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

[nikp123]

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

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

I've played around with NextCloud and grew quite resentful of it, 
unfortunately. It just has way too many performance problems to be 
useful. But I won't drag this discussion offtopic. Thanks for the 
suggestion either way.

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

Yeah, I'd fear that I would be reinventing the wheel here by suggesting 
that.

> 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.


>    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!TZBBLjzMYHOAXTQiFLRe5BaE7Dp4SecToZCFKhVgUYmtzPijKUaG1mZ-MAvOC6qYWbT_nSfWcgwN5xNfDna9bFX8ISf3Cw$ 
>    That didn't talk about ar/fp-in-synced-dir but it does now.
Awesome, that solves one piece of the puzzle.


>    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.

Thanks for the proposed ideas, I really appreciate it,

nikp123


PS: Sending this again because I forgot how e-mail works. Silly me
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://LISTS.SEAS.UPENN.EDU/pipermail/unison-hackers/attachments/20231031/cc82a383/attachment-0001.htm>