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


Reply via email to