error adding seccomp filter rule for syscall bdflush: permission denied

[cevich]

#573 Causes an error on Ubuntu when running any container using cri-o-runc 1.0.0~rc95.1. It also happens (not too unexpectedly) from buildah bud (first identified here). The problem does not occur when using the prior version of containers-common (which doesn't contain the #573 changes).

# podman --runtime=runc run -it --rm quay.io/libpod/alpine:latest echo hello
Error: container_linux.go:380: starting container process caused: error adding seccomp filter rule for syscall bdflush: permission denied: OCI permission denied

Conveniently, I have two VM Images built 3-days apart which bisect the problem versions. See test PR podman-container-tools/podman#10709

• c4635821094469632 built on the 13th does not reproduce the problem (containers-common 1_15)
• c4805484248039424 built on the 16th does reproduce the problem (containers-common 1_16)

Hint: If you check out commit 9efcf62 from that PR, you can use hack/get_ci_vm.sh int podman ubuntu-2010 root host to see it break. Commit f4c50f6 will get you the prior version VM (without the problem).

[cevich]

@giuseppe broke it 😀

Context: This isn't a problem released into the wild yet. Only seeing it in CI when testing out new VM images.

[giuseppe]

@cevich I've seen the error "container_linux.go:380: starting container process caused: error adding seccomp filter rule for syscall bdflush: permission denied: OCI permission denied" with versions of runc older than 1.0-rc95.

Could we first double check the runc version?

[ryester19]

@cevich I've seen the error "container_linux.go:380: starting container process caused: error adding seccomp filter rule for syscall bdflush: permission denied: OCI permission denied" with versions of runc older than 1.0-rc95.

Could we first double check the runc version?

Having the same problem with containers-common-0.40.0-1, and my Arch Linux setup has runc 1.0.0rc95-1

[giuseppe]

@ryester27 is it on x86_64?

Could you try with a custom seccomp profile where you drop bdflush from it?

[ryester19]

@ryester27 is it on x86_64?

Could you try with a custom seccomp profile where you drop bdflush from it?

x86_64, yes

I removed bdflush from /etc/containers/seccomp.json. Tried running another container, and then it complained about clone3. Removed that too, then complained about io_pgetevents next. And so on....

Let me know if that wasn't the right way to test this

[cevich]

Thanks @giuseppe

with versions of runc older than 1.0-rc95

I just looked, the problem images have cri-o-runc 1.0.0~rc95.1 from Kubik, but maybe it's right on the line. Is there a specific commit we can check to see if it's present or not?

Also, if we're building new packages anyway, should we also bump libseccomp (2.5.1) or anything else?

[cevich]

Tried running another container, and then it complained about clone3.

FWIW: I also tried this, and had the exact same result. It just fails on the next one in the list 😢

[cevich]

Idea: Since it should be easy to check, let me try my reproducer after rebuilding/installing from upstream runc...

[cevich]

...okay, this failure is reproducing even with the latest runc from upstream source:

# podman --runtime=/usr/local/sbin/runc run -it --rm quay.io/libpod/alpine:latest
 echo hello
Trying to pull quay.io/libpod/alpine:latest...
Getting image source signatures
Copying blob 9d16cba9fb96 done
Copying config 9617696764 done
Writing manifest to image destination
Storing signatures
Error: container_linux.go:380: starting container process caused: error adding seccomp filter rule for syscall bdflush: permission denied: OCI permission denied

# type -P runc
/usr/local/sbin/runc

# /usr/local/sbin/runc --version
runc version 1.0.0-rc95+dev
commit: v1.0.0-rc95-124-g9f937782
spec: 1.0.2-dev
go: go1.15.11
libseccomp: 2.5.1

[giuseppe]

I see what is happening. We also need an updated Podman that is using #573, otherwise some of the settings in #573 are not honored by Podman

[kris7t]

@ryester27 I'm also having this issue on Arch Linux with containers-common 0.40.0, podman 3.2.1, and runc 1.0.0rc95. However, replacing /etc/containers/seccomp.json with the file from containers-common 0.39.0 is a workaround and lets containers starts properly, albeit at the expense of less strict seccomp filters, I guess.

[rammanokar]

Issue resolved after rolling back to containers-common 0.39.0

sudo pacman -U https://archive.archlinux.org/packages/c/containers-common/containers-common-0.39.0-4-any.pkg.tar.zst