Hi @henry118. Thanks for your PR.

I'm waiting for a containerd member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

/ok-to-test

/retest-required

A fix for the prow/K8s-driven tests was just merged; if you can rebase on master we can get a clean CI run

Just some random comments/ramblings (perhaps they make no sense)

• Wondering if this should also be gated by kernel version, or would that already be taken care of by the capability not being supported by older kernels? (Not sure if it's blocked before the profile is generated)
• Are the syscalls removed from CAP_SYS_ADMIN in newer kernels, or are they gated by either? (so on kernel > 5.8 either CAP_SYS_ADMIN or CAP_BPF will give you access?)

Just some random comments/ramblings (perhaps they make no sense)
Wondering if this should also be gated by kernel version, or would that already be taken care of by the capability not being supported by older kernels? (Not sure if it's blocked before the profile is generated)

These caps are defined for kernel version 5.8 here. The latest defined known kernel version is 5.9.

Are the syscalls removed from CAP_SYS_ADMIN in newer kernels, or are they gated by either? (so on kernel > 5.8 either CAP_SYS_ADMIN or CAP_BPF will give you access?)

These syscalls were not removed from CAP_SYSTEM_ADMIN, but can be separately enabled by those two new caps. In other words both CAP_SYS_ADMIN and CAP_BPF will enable bpf syscall from 5.8 onwards.

Quoted the manpage below:

CAP_SYS_ADMIN
...              
              * perform the same BPF operations as are governed by
                CAP_BPF (but the latter, weaker capability is preferred
                for accessing that functionality).
              * employ the same performance monitoring mechanisms as are
                governed by CAP_PERFMON (but the latter, weaker
                capability is preferred for accessing that
                functionality).

/retest-required