Description

This is more of a request for comments than a bug.

Background

(a) runc and runtime-spec used to treat capabilities from config.json as a must (i.e. if a requested capability could not be set, an error must be returned).

(b) This has changed in runtime-spec since opencontainers/runtime-spec#1094. The spec now says:

Any value which cannot be mapped to a relevant kernel interface, or cannot be granted otherwise MUST be logged as a warning by the runtime. Runtimes SHOULD NOT fail if the container configuration requests capabilities that cannot be granted, for example, if the runtime operates in a restricted environment with a limited set of capabilities.

(c) The above change was partially implemented in #2854. By "partially" I mean that runc now warns, not errors, in the following two cases:

• when a capability name specified is not recognized (for example, a misspelled or made up name, or a recently added capability that runc is not yet aware);
• when a capability is known, but not (yet) supported by a currently running kernel (i.e. it's an older kernel).

(d) Also, due to a bug in capability package (fixed in it's moby/sys fork, see kolyshkin/capability#3), any error when raising an ambient capability (using prctl(PR_CAP_AMBIENT)) which is not present in both the permitted and the inheritable sets was silently ignored.

(e) For all other cases, such as when a valid (known and supported) capability can not be granted, runc still returns an error. This includes:

• dropping capabilities from the bounding set (using prctl(PR_CAPBSET_DROP)) when runc doesn't have CAP_SETPCAP(unlikely to happen);
• any errors from capset(2); quoting capset(2) man page:
• An attempt was made to add a capability to the permitted set;
• An attempt was made to set a capability in the effective set that is not in the permitted set.
• An attempt was made to add a capability to the inheritable set, and either:
  • that capability was not in the caller's bounding set; or
  • the capability was not in the caller's permitted set and the caller lacked the CAP_SETPCAP capability in its effective set.

Questions

1. In (d) above, do we want to switch from a silence to a warning (this is what libct/cap: switch to moby/sys/capability, lazy init #4358 does) or to an error?
2. In (e) above, do we want to switch from an error to a warning?

@opencontainers/runc-maintainers PTAL.