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
