podman generates redundant rules (which are rejected by runtime)

[kolyshkin]

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.

[vrothberg]

Thanks, @kolyshkin!

@rhatdan @containers/podman-maintainers are planing a 3.2.4 or is this branch frozen?

[mheon]

I would consider the branch frozen considering how close we are to 3.3.0

[rhatdan]

I agree.

[sebastian-philipp]

Since this morning the Ceph CI is broken due to due to this issue: https://tracker.ceph.com/issues/52279

[sebastian-philipp]

First time we see this in our CI was on Aug 7, 2021 6:24:44 AM UTC

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

I don't believe we have this in podman 3.3 so I am going to close.