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

[Maxim Cournoyer]

Hello,

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

> 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

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