Failure to mount /sys in nested ‘guix shell’ container

  • Open
  • quality assurance status badge
Details
2 participants
  • Josselin Poiret
  • Ludovic Courtès
Owner
unassigned
Submitted by
Ludovic Courtès
Severity
normal
L
L
Ludovic Courtès wrote on 21 Feb 2023 23:45
Failure to mount /sys in nested ‘guix shell ’ container
(address . bug-guix@gnu.org)
87v8jud4e7.fsf@inria.fr
Hi!

As reported by Konrad¹, nested ‘guix shell -C’ fails:

Toggle snippet (7 lines)
$ 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

Strace shows this:

Toggle snippet (13 lines)
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)

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:


It’s not clear whether there’s anything we can do, other than
recommending ‘-CN’ as well in the nested container.

Thoughts?

Ludo’.

J
J
Josselin Poiret wrote on 2 Mar 2023 10:54
Re: bug#61690: Failure to mount /sys in nested ‘gui x shell’ container
(name . Konrad Hinsen)(address . konrad.hinsen@cnrs.fr)
878rgflbqb.fsf@jpoiret.xyz
Hi Ludo,

Ludovic Courtès <ludovic.courtes@inria.fr> writes:

Toggle quote (7 lines)
> 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
-----BEGIN PGP SIGNATURE-----

iQHEBAEBCAAuFiEEOSSM2EHGPMM23K8vUF5AuRYXGooFAmQAclwQHGRldkBqcG9p
cmV0Lnh5egAKCRBQXkC5FhcaivbVC/9ZQQeNLZa1vxoFQ/zTIeQALu7By92JqUOU
fuK8OdcBiY+B4+ztLZt+8fQH5HdLv8RSsPkB/90qeHbXTX0f3rpa9QNIcC3rXh7Z
umDZPYTdxW3us5ZIHFVz2Pb0ITL5LKcAbd1k4C8sJlW4hGqzssmxKurIoJhrcefT
rRZxOBGUjuY4Jaf7C6gMDaOArkWDssMal7ebPKPdgkX5SXP77v/4sdt/wTqloqDP
aPfFOVY/aks75DPmiOAaZCOeRKNtJFJWvR2VrJS38YjVqjjeOabbNbioV+YnFe78
IA2lmx42PwJ5Nx3Kbo4judmPLSDf95wsK0R9eDeT07CSy+MeHxZvrKZudA6+p9xK
XQmsF+Gp6FNMKwXARJWX91PSopGDBMumou4Ivrj26NIPChSYh5LfE8O1p9ZX7TQs
JgEKzSJdQH14E0kGsx5WSxcKRSsIovGEnyKwQFI34kWhPaEGedOaB2VzQlUU3g2O
9o2+yjACjOGsC15jgogTIHOJ1o/HB4U=
=J2CF
-----END PGP SIGNATURE-----

L
L
Ludovic Courtès wrote on 2 Mar 2023 18:11
(name . Josselin Poiret)(address . dev@jpoiret.xyz)
87wn3z3wp7.fsf@inria.fr
Hi Josselin,

Josselin Poiret <dev@jpoiret.xyz> skribis:

Toggle quote (14 lines)
> Ludovic Courtès <ludovic.courtes@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’.
J
J
Josselin Poiret wrote on 2 Mar 2023 18:32
(name . Ludovic Courtès)(address . ludovic.courtes@inria.fr)
875ybjrrco.fsf@jpoiret.xyz
Hi Ludo,

Ludovic Courtès <ludovic.courtes@inria.fr> writes:

Toggle quote (5 lines)
> 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
-----BEGIN PGP SIGNATURE-----

iQHEBAEBCAAuFiEEOSSM2EHGPMM23K8vUF5AuRYXGooFAmQA3ccQHGRldkBqcG9p
cmV0Lnh5egAKCRBQXkC5FhcaikBkC/9eVZ5ipnTG8X//aP+lNFZaz4vpHhQfzkZ8
5TO2T1uJah7fAFbLLTT99fr6TyjkrbjDfoPpJbXmVhbwvYxxTorLVCRG6rVIuxFs
s90DalQLdecjD4+IPOvSWoTAlCHZIqQSgxcsuC6YUVTUrLEsy6TMDkRrKpH2DJT9
yB6lV7+dbMqFYhpUMYM9cvIqHLFH9fkPnYT+53zMF+etkgIV2ikAoAV41kV77JeO
Q/DCJ0Im1aTR3La4gjcX57fdhQW3/sXBUjrQdvlxbkROvqRQ7un1wEvVbWVAmZvd
j/ZuT0yRXAzn0NlH6mWC0Wykv/2BLP9xU/ADZpVONoLnL2zsAj9EZs/akp5l7v8Z
UL1lSHYdmntDUUhcgvBmMmvTJyzzUoPrKurNeyWYJJ0Fl79ZAiqmhs3kktU6f66x
m48rLFPGnDsCeKkoQz6Rz9BBn/ZtIS8HQoFpfmr9+LAhAgS4d9r27yDzW3iOMZwE
Km+wvCjqDBLVnJ/GLh4Lr50B7ticGvE=
=5lBa
-----END PGP SIGNATURE-----

?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 61690@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 61690
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch