GNU bug report logs -
#61690
Failure to mount /sys in nested ‘guix shell’ container
Previous Next
To reply to this bug, email your comments to 61690 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
konrad.hinsen <at> cnrs.fr, bug-guix <at> gnu.org
:
bug#61690
; Package
guix
.
(Tue, 21 Feb 2023 22:46:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Ludovic Courtès <ludovic.courtes <at> inria.fr>
:
New bug report received and forwarded. Copy sent to
konrad.hinsen <at> cnrs.fr, bug-guix <at> gnu.org
.
(Tue, 21 Feb 2023 22:46:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hi!
As reported by Konrad¹, nested ‘guix shell -C’ fails:
--8<---------------cut here---------------start------------->8---
$ guix shell -CN guix \
--expose=/var/guix/daemon-socket/socket \
--expose=/gnu/store \
-- guix shell -C coreutils -- ls /
guix shell: error: mount: mount "none" on "/tmp/guix-directory.xO3FIx/sys": Operation not permitted
--8<---------------cut here---------------end--------------->8---
Strace shows this:
--8<---------------cut here---------------start------------->8---
17541 clone(child_stack=NULL, flags=CLONE_NEWNS|CLONE_NEWCGROUP|CLONE_NEWUTS|CLONE_NEWIPC|CLONE_NEWUSER|CLONE_NEWPID|CLONE_NEWNET|SIGCHLD) = 7
[…]
17551 mount("none", "/tmp/guix-directory.d6rKy1", "tmpfs", 0, NULL) = 0
17551 mkdir("/tmp", 0777) = -1 EEXIST (File exists)
17551 mkdir("/tmp/guix-directory.d6rKy1", 0777) = -1 EEXIST (File exists)
17551 mkdir("/tmp/guix-directory.d6rKy1/proc", 0777) = 0
17551 mount("none", "/tmp/guix-directory.d6rKy1/proc", "proc", MS_NOSUID|MS_NODEV|MS_NOEXEC, NULL) = 0
17551 mkdir("/tmp", 0777) = -1 EEXIST (File exists)
17551 mkdir("/tmp/guix-directory.d6rKy1", 0777) = -1 EEXIST (File exists)
17551 mkdir("/tmp/guix-directory.d6rKy1/sys", 0777) = 0
17551 mount("none", "/tmp/guix-directory.d6rKy1/sys", "sysfs", MS_RDONLY|MS_NOSUID|MS_NODEV|MS_NOEXEC, NULL) = -1 EPERM (Operation not permitted)
--8<---------------cut here---------------end--------------->8---
It does work if the nested ‘guix shell’ uses ‘-CN’ instead of ‘-C’,
thanks to this bit in (gnu build linux-container)
(mount-file-systems root mounts
#:mount-/proc? (memq 'pid namespaces)
#:mount-/sys? (memq 'net
namespaces)) ;<---
The reason for this bug seems to be given here:
https://github.com/nestybox/sysbox/issues/67#issuecomment-726285026
It’s not clear whether there’s anything we can do, other than
recommending ‘-CN’ as well in the nested container.
Thoughts?
Ludo’.
¹ https://lists.gnu.org/archive/html/guix-devel/2023-02/msg00027.html
Information forwarded
to
bug-guix <at> gnu.org
:
bug#61690
; Package
guix
.
(Thu, 02 Mar 2023 09:55:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 61690 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi Ludo,
Ludovic Courtès <ludovic.courtes <at> inria.fr> writes:
> The reason for this bug seems to be given here:
>
> https://github.com/nestybox/sysbox/issues/67#issuecomment-726285026
>
> It’s not clear whether there’s anything we can do, other than
> recommending ‘-CN’ as well in the nested container.
Couldn't we always create a new network namespace, but when -N is passed
it also has a veth interface? The one problem I can think of is that
we'd need to either create one veth per interface in the parent
namespace or let the user specify which interface should be shared.
Best,
--
Josselin Poiret
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org
:
bug#61690
; Package
guix
.
(Thu, 02 Mar 2023 17:12:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 61690 <at> debbugs.gnu.org (full text, mbox):
Hi Josselin,
Josselin Poiret <dev <at> jpoiret.xyz> skribis:
> Ludovic Courtès <ludovic.courtes <at> inria.fr> writes:
>
>> The reason for this bug seems to be given here:
>>
>> https://github.com/nestybox/sysbox/issues/67#issuecomment-726285026
>>
>> It’s not clear whether there’s anything we can do, other than
>> recommending ‘-CN’ as well in the nested container.
>
> Couldn't we always create a new network namespace, but when -N is passed
> it also has a veth interface? The one problem I can think of is that
> we'd need to either create one veth per interface in the parent
> namespace or let the user specify which interface should be shared.
Maybe we could, but I must confess I’m totally clueless on this veth
thing. :-)
What would this entail? Hopefully guile-netlink can help?
Thanks,
Ludo’.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#61690
; Package
guix
.
(Thu, 02 Mar 2023 17:34:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 61690 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi Ludo,
Ludovic Courtès <ludovic.courtes <at> inria.fr> writes:
> Maybe we could, but I must confess I’m totally clueless on this veth
> thing. :-)
>
> What would this entail? Hopefully guile-netlink can help?
So, a veth (Virtual Ethernet) device is basically a pipe but for network
devices: they're created in pairs, and any packet going through one end
is instantly received on the other end. You can then transmit packets
between network namespaces.
One problem that totally slipped by me is that you need to be root to
create a veth device in the original namespace... Rootless containers
use slirp4netns, which is basically a userspace TCP/IP stack
communicating with a special network device in the new namespace (over
which you have complete rights). The situation might thus be a bit more
complicated, since we'd need another library/program as a dependency to
achieve this. I guess there's no best solution for now then :/
Best,
--
Josselin Poiret
[signature.asc (application/pgp-signature, inline)]
This bug report was last modified 1 year and 63 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.