>When packaging your software, this was one of the only upstream defaults
>I changed. I encountered several cases where a user might want to use
>those binaries, and did not want the software authors policy to be in
>the way there:
>
> - generating an initramfs (s6-mount was the culprit if I remember
> correctly)
> - more generally generating any kind of rootfs / copying a working
> binary from a machine where you are not root to one where you are
> - User namespaces: I tend to play with namespaces with a shared,
> ro-mounted /, but isolated /home to isolate random software. Inside
> those namespaces I start as "root" with an unshared mount namespace,
> so s6-*uidgid and s6-*mount are nice to have access to
The policy should not be an impediment for users; only binaries that
*will not work* for normal users should be 0700.
When s6-mount and s6-umount were written, it was the case; user-
accessible mounts were added later. Thanks for making me think of it:
I will relax their permissions.
Unless I'm mistaken, however, s6-setuidgid and s6-applyuidgid really
don't make any sense for non-root users. Maybe s6-applyuidgid to
restrict your own supplementary groups or change your primary group,
and still, that's a stretch.
For the "copy a hierarchy" thing, yeah, I can understand that it's
frustrating. Would 0744 be acceptable?
--
Laurent
Received on Sun Jan 09 2022 - 17:31:39 CET