Hello, Maxim Cournoyer <maxim.courno...@gmail.com> writes:
> Hi, > > Ludovic Courtès <l...@gnu.org> writes: > >> Hello! >> >> Maxim Cournoyer <maxim.courno...@gmail.com> skribis: >> >>> It was found that using something like: >>> >>> (make-forkexec-constructor >>> (least-authority >>> (list (file-append coreutils "/bin/true")) >>> (mappings (delq 'user %namespaces)) >>> #:user "nobody" >>> #:group "nobody")) >>> >>> Would fail with EPERM, because in order to be able to drop the user >>> namespace, the CAP_SYS_ADMIN capability is required, but in the above >>> case, make-forkexec-constructor has already changed the user to >>> "nobody", which lacks such capability. >> >> Thanks for the reminder! >> >> I guess the problem is limited to cases where you need the program to >> run in the global user namespace. > > Yes, it's limited to that case, because when clone(2) is called without > CLONE_NEWUSER, the child process does *not* start with a complete set of > capabilities (CAP_SYS_ADMIN), quoting my original investigation from > [0]: > >> The problem then seems to be that since we need CAP_SYS_ADMIN when >> dropping the user namespace, as CLONE_NEWUSER is what gives us >> superpowers. Per 'man user_namespaces': > >> The child process created by clone(2) with the CLONE_NEWUSER flag starts >> out with a complete set of capabilities in the new user namespace. > > [0] https://issues.guix.gnu.org/54786#16 I believe this issue was addressed in commits 7578c25b93 ("least-authority: Add support for changing UIDs/GIDs before exec.") and ca81317389 ("shepherd: Remove ‘make-forkexec-constructor/container’."). Closing! -- Thanks, Maxim