<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
On 31. 10. 23. 00:08, Greg Troxel wrote:
<br>
<blockquote type="cite" style="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="cite" style="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="cite" style="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="cite" style="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="cite" style="color: #007cff;"> 2) I think it
would be a good thing to be able to, and perhaps by
<br>
default to do so, change the location of the ar/fp files from
<br>
~/.unison to $SYNCROOT/.unison or someplace like that. We have
<br>
<a class="moz-txt-link-freetext" href="https://urldefense.com/v3/__https://github.com/bcpierce00/unison/issues/552__;!!IBzWLUs!TZBBLjzMYHOAXTQiFLRe5BaE7Dp4SecToZCFKhVgUYmtzPijKUaG1mZ-MAvOC6qYWbT_nUfWcgwN5xNfDna9bHcPJbXhhw$">https://github.com/bcpierce00/unison/issues/552</a>
<br>
That didn't talk about ar/fp-in-synced-dir but it does now.
<br>
</blockquote>
Awesome, that solves one piece of the puzzle.
<br>
<br>
<br>
<blockquote type="cite" style="color: #007cff;"> 3) With (2) done,
which I think is of general interest, then I think
<br>
-- but I may be missing something -- that adding a single
"chroot ."
<br>
call to unison, after chdir to the sync dir -- with a bit of
fixup for
<br>
paths, might mostly do what you want, and that might well be
simple
<br>
enough and more broadly applicable as to be ok in terms of
<br>
complexity/usefulness tradeoff.
<br>
</blockquote>
If this is possible, that would solve my problems. Because that <b
class="moz-txt-star"><span class="moz-txt-tag">*</span>would<span
class="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>