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.
