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 -- Thanks, Maxim
