[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#60890: least-authority-wrapper and make-forkexec-constructor composi
From: |
Maxim Cournoyer |
Subject: |
bug#60890: least-authority-wrapper and make-forkexec-constructor composition problem |
Date: |
Fri, 20 Jan 2023 08:42:25 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) |
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