Control: severity -1 normap Control: tag -1 upstream moreinfo Hello Bastian,
thanks for reporting this issue: On 5/23/20 11:46 AM, Bastian Blank wrote: > Package: slirp4netns > Version: 1.0.1-1 > Severity: important > > 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 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.