bug#60890: least-authority-wrapper and make-forkexec-constructor composition problem

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

Hi,

Ludovic Courtès <ludo@gnu.org> writes:

> Hello!
>
> Maxim Cournoyer <maxim.cournoyer@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