GNU bug report logs - #60890
least-authority-wrapper and make-forkexec-constructor composition problem

Previous Next

Package: guix;

Reported by: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>

Date: Tue, 17 Jan 2023 19:31:01 UTC

Severity: normal

Done: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 60890 in the body.
You can then email your comments to 60890 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-guix <at> gnu.org:
bug#60890; Package guix. (Tue, 17 Jan 2023 19:31:01 GMT) Full text and rfc822 format available.

Acknowledgement sent to Maxim Cournoyer <maxim.cournoyer <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-guix <at> gnu.org. (Tue, 17 Jan 2023 19:31:01 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: bug-guix <bug-guix <at> gnu.org>
Subject: least-authority-wrapper and make-forkexec-constructor composition
 problem
Date: Tue, 17 Jan 2023 14:30:03 -0500
Hi,

I'm creating a bug to keep track of a problem that was uncovered when
attempting to migrate the jami-service-type service to use the
least-authority-wrapper [0], to avoid forgetting about it.

It was found that using something like:

--8<---------------cut here---------------start------------->8---
(make-forkexec-constructor
  (least-authority
    (list (file-append coreutils "/bin/true"))
    (mappings (delq 'user %namespaces))
  #:user  "nobody"
  #:group "nobody"))
--8<---------------cut here---------------end--------------->8---

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.

The solution proposed by Ludovic in would be to [1]:

> [...] add #:user and #:group to ‘least-authority-wrapper’ and
> have it call setuid/setgid.  ‘make-forkexec-constructor’ doesn’t need to
> be modified, but the user simply won’t pass #:user and #:group to it.

[0]  https://issues.guix.gnu.org/54786#16
[1]  https://issues.guix.gnu.org/54786#17

-- 
Thanks,
Maxim




Information forwarded to bug-guix <at> gnu.org:
bug#60890; Package guix. (Thu, 19 Jan 2023 17:05:01 GMT) Full text and rfc822 format available.

Message #8 received at 60890 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: 60890 <at> debbugs.gnu.org
Subject: Re: bug#60890: least-authority-wrapper and
 make-forkexec-constructor composition problem
Date: Thu, 19 Jan 2023 18:04:18 +0100
Hello!

Maxim Cournoyer <maxim.cournoyer <at> 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.

For example, Tor does not need to run in the global user namespace, and
thus does the following:

--8<---------------cut here---------------start------------->8---
(define (tor-shepherd-service config)
  "Return a <shepherd-service> running Tor."
  (let* ((torrc (tor-configuration->torrc config))
         (tor   (least-authority-wrapper
                 (file-append (tor-configuration-tor config) "/bin/tor")
                 #:name "tor"
                 #:mappings (list …)
                 #:namespaces (delq 'net %namespaces))))
    (list (shepherd-service
           (provision '(tor))
           ;; …
           (start #~(make-forkexec-constructor
                     (list #$tor "-f" #$torrc)
                     #:user "tor" #:group "tor"))
           (stop #~(make-kill-destructor))
           (actions (list (shepherd-configuration-action torrc)))
           (documentation "Run the Tor anonymous network overlay.")))))
--8<---------------cut here---------------end--------------->8---

Here ‘make-forkexec-constructor’ calls setuid/setgid before it invokes
the wrapped program, and everything’s fine.

Ludo’.




Information forwarded to bug-guix <at> gnu.org:
bug#60890; Package guix. (Fri, 20 Jan 2023 13:43:01 GMT) Full text and rfc822 format available.

Message #11 received at 60890 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 60890 <at> debbugs.gnu.org
Subject: Re: bug#60890: least-authority-wrapper and
 make-forkexec-constructor composition problem
Date: Fri, 20 Jan 2023 08:42:25 -0500
Hi,

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

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




Reply sent to Maxim Cournoyer <maxim.cournoyer <at> gmail.com>:
You have taken responsibility. (Tue, 12 Nov 2024 05:57:02 GMT) Full text and rfc822 format available.

Notification sent to Maxim Cournoyer <maxim.cournoyer <at> gmail.com>:
bug acknowledged by developer. (Tue, 12 Nov 2024 05:57:02 GMT) Full text and rfc822 format available.

Message #16 received at 60890-done <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 60890-done <at> debbugs.gnu.org
Subject: Re: bug#60890: least-authority-wrapper and
 make-forkexec-constructor composition problem
Date: Tue, 12 Nov 2024 14:54:57 +0900
Hello,

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

> Hi,
>
> Ludovic Courtès <ludo <at> gnu.org> writes:
>
>> Hello!
>>
>> Maxim Cournoyer <maxim.cournoyer <at> 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




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Tue, 10 Dec 2024 12:24:18 GMT) Full text and rfc822 format available.

This bug report was last modified 93 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.