podman generates redundant rules (which are rejected by runtime) #11031
Description
This issue was reported quite a few times (for the last month: #10735, #10885, #11005, #11029).
TL;DR: when trying to start container, you get an error like
OCI runtime error: container_linux.go:380: starting container process caused: error adding seccomp filter rule for syscall bdflush: permission denied: OCI permission denied
or
OCI runtime error: container_linux.go:380: starting container process caused: error adding seccomp filter rule for syscall bdflush: requested action matches default action of filter
or something similar.
One particular cause of this is, since containers-common-4:1-20 rpm in F34
(see commit https://src.fedoraproject.org/rpms/containers-common/c/0b37657a909b2892af242e2875b39e5496d7ca42, possibly same in RHEL7 and 8), seccomp.json specifies
"defaultErrnoRet": 38,
plus a number of syscalls with
"action": "SCMP_ACT_ERRNO",
"errnoRet": 1
This comes from containers/common#573 (which is all good).
The problem is, containers/common is also used by podman to generate config.json for container to be started, and before containers/common#573 it silently ignores defaultErrnoRet, not propagating it from system's seccomp.json to container's config.json. As a result, we have set of rules like this:
{
"defaultAction": "SCMP_ACT_ERRNO",
"architectures": [
"SCMP_ARCH_X86_64",
"SCMP_ARCH_X86",
"SCMP_ARCH_X32"
],
"syscalls": [
{
"names": [
"bdflush",
"io_pgetevents",
"kexec_file_load",
"kexec_load",
.....
],
"action": "SCMP_ACT_ERRNO",
"errnoRet": 1
},Note there's no defaultErrnoRet, and this defaults to 1 (aka EPERM). As a result, we have a set of rules (for bdflush etc.) which have the same action as the defaultAction. Unfortunately, seccomp (and libseccomp-golang) rejects those, and so does runc (before opencontainers/runc#3109). OTOH crun skips those redundant rules (since containers/crun@08229f3fb904c5ea19a7d9).
As a result of all this, crun works, while other runtimes don't.
From the practical perspective, it will be faster to fix this in podman. To do so for v3.2, we need containers/common#689 and, once merged and a release is cut, vendor it to v3.2.
Other branches might have this issue as well -- please advise and I'll do my best to fix.