Commits on Oct 8, 2021

1. 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 <[email protected]>

   

   thaJeztah committed Oct 8, 2021
   Configuration menu

   • View commit details
   • Copy full SHA for b21568f
   • Browse repository at this point

   Copy the full SHA

   b21568f View commit details

   Browse the repository at this point in the history