Re: Multi-user, single UID ideas for Unison
nikp123 <[email protected]> Tue, 31 Oct 2023 00:53:54 +0100
| Newsgroups | gmane.network.unison.devel |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--===============7181311491622515955==
Content-Type: multipart/alternative;
boundary="------------2BNrkiE8GU9xuWm7jaNQWItE"
Content-Language: en-US
This is a multi-part message in MIME format.
--------------2BNrkiE8GU9xuWm7jaNQWItE
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable
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=20
ability to specify paths for each user despite all files being store=20
under one UID/GID pair. Maybe theirs was an afterthought and this=20
wasn't? I don't know. Even NextCloud that you mentioned afterwards also=20
stores files in a single permission UID/GID pair on disk. (But NextCloud=20
has other issues that make it unusable for me).
> You might run nextcloud instead (but not really sure how that would go=20
> as nextcloud wants you to use nextcloud interfaces and not manipulate=20
> the db).=20
I've played around with NextCloud and grew quite resentful of it,=20
unfortunately. It just has way too many performance problems to be=20
useful. But I won't drag this discussion offtopic. Thanks for the=20
suggestion either way.
> Overall, it feels like trying to reinvent unix permissions within a=20
> 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=20
that.
> You mention "would need system files", but I don't know which files=20
> and why?
IIRC, when you chroot into a SSH session, it would act as a regular=20
Linux chroot. The directory you're chroot-ing into would need to have=20
ALL of the binaries (and their dependencies) you're planning to use=20
already inside of it. This would be quite messy as you'd have to copy or=20
link those at runtime which is just prone to too many failures. It'd be=20
great if this wasn't the case and I just had a wrong understanding of it.
> =C2=A0=C2=A0 2) I think it would be a good thing to be able to, and perha=
ps by
> =C2=A0=C2=A0 default to do so, change the location of the ar/fp files from
> =C2=A0=C2=A0 ~/.unison to $SYNCROOT/.unison or someplace like that.=C2=A0=
We have
> https://urldefense.com/v3/__https://github.com/bcpierce00/unison/issues/5=
52__;!!IBzWLUs!TZBBLjzMYHOAXTQiFLRe5BaE7Dp4SecToZCFKhVgUYmtzPijKUaG1mZ-MAvO=
C6qYWbT_nSfWcgwN5xNfDna9bFX8ISf3Cw$=20
> =C2=A0=C2=A0 That didn't talk about ar/fp-in-synced-dir but it does now.
Awesome, that solves one piece of the puzzle.
> =C2=A0=C2=A0 3) With (2) done, which I think is of general interest, then=
I think
> =C2=A0=C2=A0 -- but I may be missing something -- that adding a single "c=
hroot ."
> =C2=A0=C2=A0 call to unison, after chdir to the sync dir -- with a bit of=
fixup for
> =C2=A0=C2=A0 paths, might mostly do what you want, and that might well be=
simple
> =C2=A0=C2=A0 enough and more broadly applicable as to be ok in terms of
> =C2=A0=C2=A0 complexity/usefulness tradeoff.
If this is possible, that would solve my problems. Because that *would*=20
achieve the isolation that I'm looking for. But I remain doubtful for=20
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
--------------2BNrkiE8GU9xuWm7jaNQWItE
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE html>
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DUTF-8=
">
</head>
<body>
On 31. 10. 23. 00:08, Greg Troxel wrote:
<br>
<blockquote type=3D"cite" style=3D"color: #007cff;">It strikes me that
currently filebrowser is
<br>
designed to be personal and you are using it outside of its design
<br>
assumptions.
<br>
</blockquote>
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).
<br>
<br>
<blockquote type=3D"cite" style=3D"color: #007cff;">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). </blockquote>
<br>
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.
<br>
<br>
<blockquote type=3D"cite" style=3D"color: #007cff;">Overall, it feels
like trying to reinvent unix permissions within a process (said in
a very broad brush way, not trying to be fair).
<br>
</blockquote>
<br>
Yeah, I'd fear that I would be reinventing the wheel here by
suggesting that.
<br>
<br>
<blockquote type=3D"cite" style=3D"color: #007cff;">You mention "would
need system files", but I don't know which files and why?
<br>
</blockquote>
<br>
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.
<br>
<br>
<br>
<blockquote type=3D"cite" style=3D"color: #007cff;">=C2=A0=C2=A0 2) I t=
hink it
would be a good thing to be able to, and perhaps by
<br>
=C2=A0=C2=A0 default to do so, change the location of the ar/fp files=
from
<br>
=C2=A0=C2=A0 ~/.unison to $SYNCROOT/.unison or someplace like that.=
=C2=A0 We have
<br>
=C2=A0=C2=A0=C2=A0=C2=A0 <a class=3D"moz-txt-link-freetext" href=3D"h=
ttps://urldefense.com/v3/__https://github.com/bcpierce00/unison/issues/552_=
_;!!IBzWLUs!TZBBLjzMYHOAXTQiFLRe5BaE7Dp4SecToZCFKhVgUYmtzPijKUaG1mZ-MAvOC6q=
YWbT_nUfWcgwN5xNfDna9bHcPJbXhhw$">https://github.com/bcpierce00/unison/issu=
es/552</a>
<br>
=C2=A0=C2=A0 That didn't talk about ar/fp-in-synced-dir but it does n=
ow.
<br>
</blockquote>
Awesome, that solves one piece of the puzzle.
<br>
<br>
<br>
<blockquote type=3D"cite" style=3D"color: #007cff;">=C2=A0=C2=A0 3) Wit=
h (2) done,
which I think is of general interest, then I think
<br>
=C2=A0=C2=A0 -- but I may be missing something -- that adding a single
"chroot ."
<br>
=C2=A0=C2=A0 call to unison, after chdir to the sync dir -- with a bi=
t of
fixup for
<br>
=C2=A0=C2=A0 paths, might mostly do what you want, and that might wel=
l be
simple
<br>
=C2=A0=C2=A0 enough and more broadly applicable as to be ok in terms =
of
<br>
=C2=A0=C2=A0 complexity/usefulness tradeoff.
<br>
</blockquote>
If this is possible, that would solve my problems. Because that <b
class=3D"moz-txt-star"><span class=3D"moz-txt-tag">*</span>would<span
class=3D"moz-txt-tag">*</span></b> achieve the isolation that I'm
looking for. But I remain doubtful for the reasons I wrote above.
<br>
<br>
Thanks for the proposed ideas, I really appreciate it,
<br>
<p>nikp123</p>
<p><br>
</p>
<p>PS: Sending this again because I forgot how e-mail works. Silly
me<br>
</p>
</body>
</html>
--------------2BNrkiE8GU9xuWm7jaNQWItE--
--===============7181311491622515955==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Unison-hackers mailing list
[email protected]
https://LISTS.SEAS.UPENN.EDU/mailman/listinfo/unison-hackers
--===============7181311491622515955==--