slirp4netns fails with the following command line:
| /usr/bin/slirp4netns --disable-host-loopback --mtu 65520 --enable-sandbox --enable-seccomp -c -e 3 -r 4 --netns-type=path /run/user/1000/netns/cni-b5f1fc5... tap0

Excerpt from strace output:

| prctl(PR_CAPBSET_DROP, CAP_BLOCK_SUSPEND) = 0
| prctl(PR_CAPBSET_DROP, CAP_AUDIT_READ)  = 0
| prctl(PR_CAPBSET_DROP, 0x26 /* CAP_??? */) = -1 EINVAL (Invalid argument)
| capset({version=_LINUX_CAPABILITY_VERSION_3, pid=0}, {effective=1<<CAP_NET_BIND_SERVICE, permitted=1<<CAP_NET_BIND_SERVICE, inheritable=1<<CAP_NET_BIND_SERVICE}) = 0
| write(2, "enable_seccomp failed\n", 22) = 22

Bastian

Hello Bastian,

thanks for reporting this issue:
I note that --enable-seccomp is (still) marked as experimental.

Also, I'm having difficulties with reproducing this issue. Here is the test case that I tried:

siretart@x1:/tmp$ unshare -rn
root@x1:/tmp# uname -a
Linux x1 5.6.0-1-amd64 #1 SMP Debian 5.6.7-1 (2020-04-29) x86_64 GNU/Linux
root@x1:/tmp# /usr/bin/slirp4netns --disable-host-loopback --mtu 65520 --enable-sandbox --enable-seccomp -c  $$ tap0
WARNING: Support for seccomp is experimental
sent tapfd=5 for tap0
received tapfd=5
Starting slirp
* MTU:             65520
* Network:         10.0.2.0
* Netmask:         255.255.255.0
* Gateway:         10.0.2.2
* DNS:             10.0.2.3
* Recommended IP:  10.0.2.100
seccomp: The following syscalls will be blocked by seccomp: execve execveat open_by_handle_at ptrace prctl process_vm_readv process_vm_writev mount name_to_handle_at setns umount umount2 unshare.


So enabling seccomp as is seems to work on kernel 5.5. However, your command-line doesn't work for me directly, I fail to reproduce the "prctl" and "capset" syscall from your example.

Can you please elaborate on your use-case and ideally demonstrate with a minimal testcase? - What kind of namespaces are shared/unshared? The command-line looks like it was generated by some other proram. Please elaborate.

Also, may I suggest that you report this issue upstream at https://github.com/rootless-containers/slirp4netns/issues/new/choose so that upstream can assist you more efficiently?
Your report does look similar to https://github.com/rootless-containers/slirp4netns/issues/196, but I'm not sure.

Hello Bastian,

thanks for reporting this issue:
I note that --enable-seccomp is (still) marked as experimental.

Also, I'm having difficulties with reproducing this issue. Here is the test case that I tried:

siretart@x1:/tmp$ unshare -rn
root@x1:/tmp# uname -a
Linux x1 5.6.0-1-amd64 #1 SMP Debian 5.6.7-1 (2020-04-29) x86_64 GNU/Linux
root@x1:/tmp# /usr/bin/slirp4netns --disable-host-loopback --mtu 65520 --enable-sandbox --enable-seccomp -c  $$ tap0
WARNING: Support for seccomp is experimental
sent tapfd=5 for tap0
received tapfd=5
Starting slirp
* MTU:             65520
* Network:         10.0.2.0
* Netmask:         255.255.255.0
* Gateway:         10.0.2.2
* DNS:             10.0.2.3
* Recommended IP:  10.0.2.100
seccomp: The following syscalls will be blocked by seccomp: execve execveat open_by_handle_at ptrace prctl process_vm_readv process_vm_writev mount name_to_handle_at setns umount umount2 unshare.


So enabling seccomp as is seems to work on kernel 5.5. However, your command-line doesn't work for me directly, I fail to reproduce the "prctl" and "capset" syscall from your example.

Can you please elaborate on your use-case and ideally demonstrate with a minimal testcase? - What kind of namespaces are shared/unshared? The command-line looks like it was generated by some other proram. Please elaborate.

Also, may I suggest that you report this issue upstream at https://github.com/rootless-containers/slirp4netns/issues/new/choose so that upstream can assist you more efficiently?
Your report does look similar to https://github.com/rootless-containers/slirp4netns/issues/196, but I'm not sure.

Hi Reinhard

I today tried some new stuff:
- podman (https://github.com/containers/libpod)
- usernetes (https://github.com/rootless-containers/usernetes)

With podman slirp4netns broke with the mentioned error.  With
rootlesskit, used by usernetes, it seems to work.  Let's see if I manage
to look again.

Bastian

Are you using the packaged podman that we have in Debian since a couple of days now, or did you compile yourself?
The packaged version does work just fine for me with slirp4netns.

I didn't have the chance to look at usernetes yet.

In any case, please do file a ticket upstream and please cc me to get some clarification from upstream.

Best,
-rt

https://github.com/containers/podman/issues/6967

It seems that Debian’s slirp4netns is rather out of date at this point and suffers compatibility issues with newer environments. Could we get an update?

We believe that the bug you reported is fixed in the latest version of
slirp4netns, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 961363@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Reinhard Tartler <siretart@tauware.de> (supplier of updated slirp4netns package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Fri, 15 Jul 2022 02:38:45 -0400
Source: slirp4netns
Architecture: source
Version: 1.2.0-1
Distribution: unstable
Urgency: medium
Maintainer: Reinhard Tartler <siretart@tauware.de>
Changed-By: Reinhard Tartler <siretart@tauware.de>
Closes: 961363
Changes:
 slirp4netns (1.2.0-1) unstable; urgency=medium
 .
   * New upstream version, Closes: #961363
Checksums-Sha1:
 f91fcd9301a7e2d0a6427fa7e2aee39ccfff2ebe 2105 slirp4netns_1.2.0-1.dsc
 946ec8b117908ef77131975584e95599cadb5e4a 62617 slirp4netns_1.2.0.orig.tar.gz
 0940f06a6d9ae91549a2ed2ee200657cf3b29d21 3680 slirp4netns_1.2.0-1.debian.tar.xz
Checksums-Sha256:
 2fce1bbfab8e2396cc6f9a7cdc8af14a4fe65c071d0970247e7a08eb3b37e70a 2105 slirp4netns_1.2.0-1.dsc
 b584edde686d3cfbac210cbdb93c4b0ba5d8cc0a6a4d92b9dfc3c5baec99c727 62617 slirp4netns_1.2.0.orig.tar.gz
 47511134be5a7dc84a971a2bd2af37cd443039a7bd0d60a06170358651823abb 3680 slirp4netns_1.2.0-1.debian.tar.xz
Files:
 7b686ddac489261c4e3172b0a47ec21c 2105 misc optional slirp4netns_1.2.0-1.dsc
 bca513a718aa9a30817919c701566f02 62617 misc optional slirp4netns_1.2.0.orig.tar.gz
 446cc255d3ddd4d11bc8f47920c7a800 3680 misc optional slirp4netns_1.2.0-1.debian.tar.xz
-----BEGIN PGP SIGNATURE-----

iQJIBAEBCgAyFiEEMN59F2OrlFLH4IJQSadpd5QoJssFAmLRD80UHHNpcmV0YXJ0
QHRhdXdhcmUuZGUACgkQSadpd5QoJsvvog/9FJor2JgQVruwRylyf5w1LEXzJD6j
DjmePFGhQQ7byBuNSVpyERL5Unc+TK2VHhoKGyhtdf5CkCscjL/shGxdYlC2fFxQ
H1nwz+6aIOnnYtit+4t/th8t8I4Ss6N9pVKnZqEFhfTQS3ezhGhk+gIEvMoZExwh
tMVVCy5UghSrY3y4E+d2Z7RUI4GqSAj1lTDouxrTw3NZmavry2MkJb510QzCmEMy
PFiffRY7aN2g9YIOaixW1UWiyccMp6ee8U9BPaInQ6oUzQVcuabQxOyXjZaZfYkU
1ygVj9xWXl9gbX0/k71UlrcQ8pXn62fgzJIiFmPskNhArlTKikrAA7MBzm2qvtlw
LhpLsPHbP50TGEvRe8eDFK3Ddy7drV3iJ4Yyu1DN9xuKFX0KV/6GKj43CladH029
48jQsNophZUM5M4NQ+pyhraaaTse+jQrmum4YcSHZXlOUUgKYeip+4F2WBXyyvTw
nIk4/59mh1VGPN8xO6qM9NYv+b5bv903H7jZjXPLIliWjxWvh6AB1F4PvkLqiIX1
K86r/kKmdGyF4VvzFZIsqnOz4jwDrjGe5SNGlVrtAKfrX4oIz/JrGhnB0R2bKANf
Vfe4wLlVTbS/v05DKKA8Qlmw5JVY2qZlr+CUFyoa34OfQUfsy+lSmp1LvsmgJIA9
MMxdmK9js4x10QQ=
=1Hen
-----END PGP SIGNATURE-----