Closed GeoffWilliams closed 4 years ago
same issue, CentOS 7.7.1908, podman updated from RPM (from the devel_kubic_libcontainers_stable
repo):
$ podman restart squidproxy
Error: /usr/bin/slirp4netns failed: "sent tapfd=7 for tap0\nWARNING: Support for sandboxing is experimental\nWARNING: Support for seccomp is experimental\nreceived tapfd=7\ncannot remount / as read-only\nenable_seccomp failed\ndo_slirp is exiting\ndo_slirp failed\nparent failed\nWARNING: Support for sandboxing is experimental\nWARNING: Support for seccomp is experimental\nStarting slirp\n* MTU: 65520\n* Network: 10.0.2.0\n* Netmask: 255.255.255.0\n* Gateway: 10.0.2.2\n* DNS: 10.0.2.3\n* Recommended IP: 10.0.2.100\nseccomp: The following syscalls will be blocked by seccomp:"
(starting a new copy of the container has same issue)
Version: 1.9.0
RemoteAPI Version: 1
Go Version: go1.13.6
OS/Arch: linux/amd64
since using --network=host
works for @GeoffWilliams , it's likely an issue with slirp4netns setting up rootless networking.. re that utility, i am running version 0.4.3 (from slirp4netns-0.4.3-23.8.x86_64
rpm (from the SuSE tumbleweed repo to work-around this issue), build date Wed Mar 18 23:16:43 2020).
perusing issues in the slirp4netns project: perhaps a possibly cross-reference to https://github.com/rootless-containers/slirp4netns/issues/192 ?
A different work-around i came up with that i'd rather use instead (which doesn't require you to attach your container to the host networking), is creating a wrapper script for slirp4netns, which re-disables seccomp (with the standard caveats/disclaimers when it comes to disabling any kind of security feature):
sudo mv /usr/bin/slirp4netns{,.real}
echo -e '#!/usr/bin/env bash\n\nexec /usr/bin/slirp4netns.real ${*/--enable-seccomp/}' | sudo tee -a /usr/bin/slirp4netns >/dev/null
sudo chmod +x /usr/bin/slirp4netns
This would need to be undone whenever you update/re-install the slirp4netns package
Update: this workaround is not recommended as a panacea, as it does not seem to work on all my CentOS systems, i get a cgroup namespaces aren't enabled in the kernel: OCI runtime error
error on other systems, when trying to not enable seccomp (perhaps seccomp is related to this check failing).
@giuseppe @AkihiroSuda Sounds like a slirp issue here - PTAL
Can't reproduce the issue with Podman v1.9.0 + slirp4netns v1.0.0 + libseccomp v2.4.1 on Ubuntu 19.10. Does slirp4netns v1.0.0 work?
I'll let the OP (@GeoffWilliams ) comment if that combination works for him on Ubuntu, however that combination does not work for me (on CentOS 7.7):
$ podman version
Version: 1.9.0
RemoteAPI Version: 1
Go Version: go1.13.6
OS/Arch: linux/amd64
latest slirp4netns binary sourced from here the releases page of the project
$ slirp4netns --version
slirp4netns version 1.0.0
commit: a3be729152a33e692cd28b52f664defbf2e7810a
libslirp: 4.2.0
the official centos repo only provided libseccomp 2.3.1, i sourced 2.4.1 from here.
$ rpm -qi libseccomp
Name : libseccomp
Version : 2.4.1
Release : 0.el7
Architecture: x86_64
Install Date: Mon Apr 20 13:45:54 2020
Group : Unspecified
Size : 333624
License : LGPLv2
Signature : (none)
Source RPM : libseccomp-2.4.1-0.el7.src.rpm
Build Date : Sat Aug 17 19:36:02 2019
Build Host : c1bd.rdu2.centos.org
Relocations : (not relocatable)
Packager : CBS <cbs@centos.org>
Vendor : CentOS
URL : https://github.com/seccomp/libseccomp
Summary : Enhanced seccomp library
Description :
The libseccomp library provides an easy to use interface to the Linux Kernel's
syscall filtering mechanism, seccomp. The libseccomp API allows an application
to specify which syscalls, and optionally which syscall arguments, the
application is allowed to execute, all of which are enforced by the Linux
Kernel.
What's unusual is that, containers i created before with the older podman 1.8.2 can still be re-started, however i can't start new ones.. So to me this seems like there's something with the container setup process related to enabling seccomp by default now.
Is there anyway to stop from having seccomp always be enabled (probably because of this PR ) please ?? this is a pretty bad issue as podman is useless for launching containers now :-(
Can't reproduce the issue with Podman v1.9.0 + slirp4netns v1.0.0 + libseccomp v2.4.1 on Ubuntu 19.10. Does slirp4netns v1.0.0 work?
@AkihiroSuda can you please also try on centos 7 system please? A lot of people are setting up podman via a repo from the opensuse kubic project (especially considering the official podman page recommends using it on the install page ), which now means they all end up with a version combination that is effectively useless for running podman in rootlessmode.
It would be good to help figure where the mismatch of versions is so they can update the package versions in the repo.
On CentOS 7, I can hit the issue with the slirp4netns upstream static binary (https://github.com/rootless-containers/slirp4netns/releases/download/v1.0.0/slirp4netns-x86_64), but the issue doesn't seem to happen when I build slirp4netns on CentOS 7.
i.e. This is likely to be version mismatch of libseccomp .
@cyphar @saschagrunert Could you update slirp4netns packages on Kubic? Also please make sure to use the latest CentOS 7 for building CentOS 7 RPMs, and the latest Ubuntu 19.10 for Ubuntu 19.10 dpkgs.
@cyphar @saschagrunert Could you update slirp4netns packages on Kubic?
I think @lsm5 is currently maintaining the upstream packages in OBS. Can we somehow update the ubuntu dependencies there?
I think lsm5 is currently maintaining the upstream packages in OBS. Can we somehow update the ubuntu dependencies there?
i've pinged him about updating slirp4netns already earlier and he mentioned it should now be updated
should be done for all except ubuntu 18.04 where it's giving me some weird error that I haven't quite figured out. Hope that one can wait ..
Updated system and now have packages:
I'm still getting the original error though. System is fully up-to-date:
geoff@computer:~$ podman run -ti alpine
Error: /usr/bin/slirp4netns failed: "sent tapfd=7 for tap0\nWARNING: Support for seccomp is experimental\nreceived tapfd=7\nenable_seccomp failed\ndo_slirp is exiting\ndo_slirp failed\nparent failed\nWARNING: Support for seccomp is experimental\nStarting slirp\n* MTU: 65520\n* Network: 10.0.2.0\n* Netmask: 255.255.255.0\n* Gateway: 10.0.2.2\n* DNS: 10.0.2.3\n* Recommended IP: 10.0.2.100\nseccomp: The following syscalls will be blocked by seccomp:"
Also tried with https://github.com/rootless-containers/slirp4netns/releases/tag/v1.0.0 ~which I tested by placing first on path - same issue~ by replacing the file at /usr/bin/slirp4netns
and chmod +x
ing it and this works
Updated system and now have packages:
* libslirp0:amd64 4.2.0~4 * slirp4netns 1.0.0~1
I'm still getting the original error though. System is fully up-to-date:
geoff@computer:~$ podman run -ti alpine Error: /usr/bin/slirp4netns failed: "sent tapfd=7 for tap0\nWARNING: Support for seccomp is experimental\nreceived tapfd=7\nenable_seccomp failed\ndo_slirp is exiting\ndo_slirp failed\nparent failed\nWARNING: Support for seccomp is experimental\nStarting slirp\n* MTU: 65520\n* Network: 10.0.2.0\n* Netmask: 255.255.255.0\n* Gateway: 10.0.2.2\n* DNS: 10.0.2.3\n* Recommended IP: 10.0.2.100\nseccomp: The following syscalls will be blocked by seccomp:"
Also tried with https://github.com/rootless-containers/slirp4netns/releases/tag/v1.0.0 ~which I tested by placing first on path - same issue~ by replacing the file at
/usr/bin/slirp4netns
andchmod +x
ing it and this works
@AkihiroSuda could this be because the deb package didn't have a static binary? or is it an older seccomp to blame?
@giuseppe suggested building slirp4netns without seccomp enabled. I'll try to get those out on the testing repo soon..
the packages from https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/CentOS_7/x86_64/ work well for me on CentOS 7.
Please try these commands:
$ unshare -rn sleep 100 &
$ slirp4netns -c --enable-seccomp $! tap0
WARNING: Support for seccomp is experimental
sent tapfd=5 for tap0
received tapfd=5
Starting slirp
* MTU: 1500
* 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
WARNING: 127.0.0.1:* on the host is accessible as 10.0.2.2 (set --disable-host-loopback to prohibit connecting to 127.0.0.1:*)
seccomp: can't block execevat because __NR_execveat was not defined in the build environment
seccomp: The following syscalls will be blocked by seccomp: execve open_by_handle_at ptrace prctl process_vm_readv process_vm_writev mount name_to_handle_at setns umount umount2 unshare.
Does slirp4netns exit with error?
The seccomp messages are just warnings that you can ignore.
the packages from https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/CentOS_7/x86_64/ work well for me on CentOS 7.
the podman 1.9.0 packages from this repo only now finally work cleanly on my CentOS 7 systems, in rootless mode, with the addition of the following /etc/containers/containers.conf
contents:
[containers]
cgroupns = "host"
[engine]
cgroup_manager = "cgroupfs"
events_logger = "file"
with the first section to work around this issue and the second section is due to this issue
also while I appreciate the attention for CentOS, @GeoffWilliams 's issue is on Ubuntu 19.10 :-)
Does slirp4netns exit with error?
no, it stays in the foreground.. think that's good.
A friendly reminder that this issue had no activity for 30 days.
Can anyone retry this with Podman v1.9.2 or later and report if it's fixed? I suspect that we've caught it already
Reopen if this is not fixed.
This issue is happening for me on a fully updated Fedora 32 as of today on ppc64le:
$ podman run -v guix:/src/guix:Z -it registry.gitlab.com/lle-bout/guix:latest /bin/bash
Trying to pull registry.gitlab.com/lle-bout/guix:latest...
Getting image source signatures
Copying blob e7edab824d5f done
Copying blob fd827a7d77b1 done
Copying blob b9183a6c55fb done
Copying config f9db71b17f done
Writing manifest to image destination
Storing signatures
Error: /usr/bin/slirp4netns failed: "sent tapfd=7 for tap0\nWARNING: Support for seccomp is experimental\nreceived tapfd=7\nseccomp: can't add extra arch (i=0)\nenable_seccomp failed\ndo_slirp is exiting\ndo_slirp failed\nparent failed\nWARNING: Support for seccomp is experimental\nStarting slirp\n* MTU: 65520\n* Network: 10.0.2.0\n* Netmask: 255.255.255.0\n* Gateway: 10.0.2.2\n* DNS: 10.0.2.3\n* Recommended IP: 10.0.2.100\n"
Version of podman is 2.0.1
I note:
seccomp: can't add extra arch (i=0)
but it used to work before on that same machine
Me too. I'm running podman on Debian 10 cloud with the newest Kubic package.
Please open a new issue for that. The issue here is very different and has been closed many weeks ago.
@giuseppe @AkihiroSuda, you may be interested in it.
@vrothberg Seeing the comments and the fact it was closed after being stale, I wasnt sure whether it was certain it was solved or not. Opened another here: https://github.com/containers/podman/issues/6922
/kind bug
podman run
fails on Ubuntu 19.10 withThe following syscalls will be blocked by seccomp:
After upgrading from podman 1.8.2 today, I'm unable to run any containers.
Steps to reproduce the issue:
Install podman on (X)Ubuntu 19.10 following the instructions from https://podman.io/getting-started/installation. I'm using the OpenSUSE/Kubic Project debs. Error occurs on both
stable
andtesting
channelsRun a docker image
Describe the results you received:
Fails to run, message about
syscalls blocked by seccomp
Describe the results you expected:
Expected container to start. This was the case with the previous version of podman. The repository seems to purge older version so I can't easily downgrade.
Output of
podman version
:Output of
podman info --debug
:Package info (e.g. output of
rpm -q podman
orapt list podman
):Additional environment details (AWS, VirtualBox, physical, etc.):
This is a regular Xubuntu 19.10 linux workstation running on a laptop. Prevous podman version 1.8.2 worked with no issue:
Same command in debug mode:
Workaround In an unrelated issue I found a workaround: Run with
--network=host
, eg:works