Re: s6-applyuidgid mode 0700
Yes, you are missing a potential setup for unprivileged user namespaces. (...) Yes, 0744 would be acceptable for the "copy a hierarchy thing". The user namespace thing would require at least 0755 though. All right, all right. The git heads for s6 and s6-linux-utils now have more relaxed permissions for supposedly root-only binaries. -- Laurent
Re: s6-applyuidgid mode 0700
On Sun, Jan 09, 2022 at 04:31:39PM +, Laurent Bercot wrote: > 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. Yes, you are missing a potential setup for unprivileged user namespaces. There can be multiple u/gids assigned to a user namespace (usually in the high >= 10 range outside the namespace), providing a "fake" root user (e.g. 10 outside the namespace) to start with and several "fake" unprivileged users (e.g. >= 11 outside the namespace) to drop to. This is how unmodified distributions can run in the container solution of your choice without falling over themselves because they assume there are unprivileged u/gids available when installing packages. To unprivileged users such ranges are available if they have been assigned to them by the admin in /etc/sub(u|g)id. Then the suid shadow utilities newuidmap(1) or newgidmap(1) can be used to create u/gid mappings. (Normally unprivileged users are only allowed to create a 1 u/gid long range mapping to their own u/gid.) In such a namespace s6-setuidgid would make sense to use to be able to drop privileges from that "fake" root to another "fake" unprivileged user. > For the "copy a hierarchy" thing, yeah, I can understand that it's > frustrating. Would 0744 be acceptable? Yes, 0744 would be acceptable for the "copy a hierarchy thing". The user namespace thing would require at least 0755 though.
Re: s6-applyuidgid mode 0700
Laurent, Since each of these functions already enforces guardrails required to keep the OS safe, what is the motivation to have the mode set to 0700 instead of the more permissive 0755 ? As you said, it would do no good for normal users to run these programs, so there's no point in giving them the necessary permissions. The particular use case that triggered my question is that of a unit/integration test. While s6-applyuidgid is only generally useful for root, it has a well defined outcome which is sufficient for this scenario (ie current uid == target uid, etc). This can allow testing as an unprivileged user, running the command lines using s6-applyuidgid unaltered. If s6-applyuidgid is only runnable by root, then either the test needs to run as root, or the command lines must be conditionalised to accommodate the test scenarios, or the case where current uid == target uid. What do you think? Earl
Re: s6-applyuidgid mode 0700
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
Re: s6-applyuidgid mode 0700
In case it actually went out: sorry for the first reply without content - I prematurely pressed "send". On Sun, Jan 09, 2022 at 10:30:54AM +, Laurent Bercot wrote: > As you said, it would do no good for normal users to run these > programs, so there's no point in giving them the necessary permissions. 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
Re: s6-applyuidgid mode 0700
On Sun, Jan 09, 2022 at 10:30:54AM +, Laurent Bercot wrote: > > Since each of these functions already enforces guardrails required > > to keep the OS safe, what is the motivation to have the mode set to > > 0700 instead of the more permissive 0755 ? > > As you said, it would do no good for normal users to run these > programs, so there's no point in giving them the necessary permissions. > To me it serves as useful metadata: "this binary is only meant to be > used by root" - permissions on the binary itself have always felt like > a better indicator to me than location in /bin or /sbin.
Re: s6-applyuidgid mode 0700
Since each of these functions already enforces guardrails required to keep the OS safe, what is the motivation to have the mode set to 0700 instead of the more permissive 0755 ? As you said, it would do no good for normal users to run these programs, so there's no point in giving them the necessary permissions. To me it serves as useful metadata: "this binary is only meant to be used by root" - permissions on the binary itself have always felt like a better indicator to me than location in /bin or /sbin. -- Laurent
s6-applyuidgid mode 0700
AFAIU s6-applyuidgid calls setuid(2), setgid(2), and setgroups(2). Since each of these functions already enforces guardrails required to keep the OS safe, what is the motivation to have the mode set to 0700 instead of the more permissive 0755 ? Earl
