Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
libct/capabilities: create capabilities map based on current environment
Commit 5fb831a changed the behavior of runc to match the OCI runtime spec, which now describes that unknown or unavailable capabilities should be ignored. While this change addressed situations where a capability was requested that's not supported by the current kernel ("unknown capabilities"), it did not take into account situations where the kernel *supports* a capability, but that capability is not *available* in the current environment. This causes issues if, for example, runc is running in a docker-in-docker setup, and the outer container does not have all known capabilities enabled, either on purpose (for example, Talos version 0.13 drops two capabilities (kexec + module loading) from all processes but PID 1), or because the outer container was created by an older version of docker or runc, which did not yet support newer capabilities. 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, with some modifications: - the full list of capabilities uses github.com/syndtr/gocapability, instead of a self-defined list. Containerd removed the use of github.com/syndtr/gocapability, but this dependency is still in use in runc, so this change makes it a closer match to the current code. - functions where un-exported, as we don't intend them to be used externally. - a sync.Once was added to the .current() function, so that /proc/self/status is only parsed once. This assumes effective capabilities do not change during runc's lifecycle. There are some things left to be looked at: 1. current() may return an error when failing to parse /proc/self/status, but this error is currently ignored. If an error occurs in this code, it will mean that *no* capabilities are known. While this will be logged as warning when attempting to apply capabilities, it's not a very desirable situation. We'll have to decide what to do in that situation, which could be "panic" (runc unable to run success- fully), or "fall back to a safe/default list". 2. the current code applies the same list (effective caps) to every "type" (ambient, inheritable, bounding, ...). When applying capabilities, should each of those types in the container's spec be limited to the _corresponding_ type in the current processes' capabilities? 3. integration test: we may want an integration test for this. 4. do we want to upstream this functionality to github.com/syndtr/gocapability ? Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- Loading branch information