oci/caps: limit available capabilities to current environment

[thaJeztah]

fixes #42906 docker container is privileged tries to assume more capabilities than available
replaces / closes #42911 fix: don't attempt to set unavailable capabilities in privileged mode
fixes #42892 Recent test failures in CI (apply caps: operation not permitted) - except for TestHealthKillContainer, which is tracked in #41930)

Relates to:

• libct/capabilities: create capabilities map based on current environment opencontainers/runc#3240 libct/capabilities: create capabilities map based on current environment
• fix: provide only available capabilities to insecure environment buildkit#2394 fix: provide only available capabilities to insecure environment
• capabilities: WARN, not ERROR, for unknown / unavailable capabilities opencontainers/runc#2854 capabilities: WARN, not ERROR, for unknown / unavailable capabilities
• runtime should WARN / ignore capabilities that cannot be granted opencontainers/runtime-spec#1094 runtime should WARN / ignore capabilities that cannot be granted

In situations where docker runs in an environment where capabilities are limited,
sucn as docker-in-docker in a container created by older versions of docker, or
in a container where some capabilities have been disabled, starting a privileged
container may fail, because even though the kernel supports a capability, the
capability is not available.

This patch attempts to address this problem by limiting the list of "known" capa-
bilities on the set of effective capabilties for the current process. This code
is based on the code in containerd's "caps" package

- Description for the changelog

Detect list of available capabilities based on current environment, to allow running privileged containers in environments with a restricted set of capabilities.

- A picture of a cute animal (not mandatory but encouraged)

[AkihiroSuda]

Can we just use https://github.com/containerd/containerd/blob/08557253700839e39760a0ee05670ea305f7a836/pkg/cap/cap_linux.go#L120 ?

[thaJeztah]

Looks like this doesn't solve one of the new test failures;

=== RUN   TestHealthKillContainer
    health_test.go:62: timeout hit after 10s: waiting for container to become healthy
--- FAIL: TestHealthKillContainer (12.48s)

[AkihiroSuda]

TestHealthKillContainer

I guess that one is unrelated to caps?

[thaJeztah]

I guess that one is unrelated to caps?

Yes, it looks unrelated to that. That test was already "flaky" #41930, but started failing 100% (?) at the same time as the capabilities issue occurred, which was when Jenkins agents were updated to kernel 5.11 (#42892), so I was hoping it would be related (and fixed by this PR), but more digging is needed for that one (perhaps it's just a race condition somehow)

[thaJeztah]

Other than that, I updated this to use the containerd package and drop the go capabilities dependency as you suggested, so PTAL

There's still some code in the moby repository to do the capability "tweaking", and for the error handling etc, but tried to keep it close to what we had.

[thaJeztah]

@tonistiigi PTAL

[thaJeztah]

Only remaining failure is TestHealthKillContainer, which is tracked in #41930.

I'm bringing this one in; CI was just retriggered because I edited the top comment 😞, but it was "green" otherwise before