Adds support for Windows container images built by Docker
that contain the ArgsEscaped boolean in the ImageConfig. This
is a non-OCI entry that tells the runtime that the Entrypoint
and/or Cmd are a single element array with the args pre-escaped
into a single CommandLine that should be passed directly to
Windows rather than passed as an args array which will be
additionally escaped.
Signed-off-by: Justin Terry <jlterry@amazon.com>
CRI container runtimes mount devices (set via kubernetes device plugins)
to containers by taking the host user/group IDs (uid/gid) to the
corresponding container device.
This triggers a problem when trying to run those containers with
non-zero (root uid/gid = 0) uid/gid set via runAsUser/runAsGroup:
the container process has no permission to use the device even when
its gid is permissive to non-root users because the container user
does not belong to that group.
It is possible to workaround the problem by manually adding the device
gid(s) to supplementalGroups. However, this is also problematic because
the device gid(s) may have different values depending on the workers'
distro/version in the cluster.
This patch suggests to take RunAsUser/RunAsGroup set via SecurityContext
as the device UID/GID, respectively. The feature must be enabled by
setting device_ownership_from_security_context runtime config value to
true (valid on Linux only).
Signed-off-by: Mikko Ylinen <mikko.ylinen@intel.com>
Looks like we had our own copy of the "getDevices" code already, so use
that code (which also matches the code that's used to _generate_ the spec,
so a better match).
Moving the code to a separate file, I also noticed that the _unix and _linux
code was _exactly_ the same (baring some `//nolint:` comments), so also
removing the duplicated code.
With this patch applied, we removed the dependency on the libcontainer/devices
package (leaving only libcontainer/user).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This enables cases where devices exist in a subdirectory of /dev,
particularly where those device names are not portable across machines,
which makes it problematic to specify from a runtime such as cri.
Added this to `ctr` as well so I could test that the code at least
works.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
On Windows we need to be able to create both Linux and Windows OCI spec
files by default to support WCOW and LCOW scenarios. This merges the
compile time differences into runtime differences between the two based
on the spec and platform the user sets.
It maintains the old behavior with Default specs resulting in the
platform default the binary is compiled for.
Signed-off-by: Justin Terry (VM) <juterry@microsoft.com>
These opts either inherit the parent cgroup device.list or append the
default unix devices like /dev/null /dev/random so that the container
has access.
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
The behaviour was changed in 99df1a9e11 ("Set gid 0 when no group is
specified"), part of #2529.
Take the opportunity to tighten up the grammar a bit too.
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
This change is to match Docker's implementaion of setting gid and groups
to 0 when no gid is specified but an explicit uid is set.
Fixes#2527
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
This allows users to provide args for the process arguments while
creating the base spec with an image. It provides the same symantics as
Docker where additional args replace the CMD while leaving the
ENTRYPOINT the same.
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
This change allows implementations to resolve the location of the actual data
using OCI descriptor fields such as MediaType.
No OCI descriptor field is written to the store.
No change on gRPC API.
Signed-off-by: Akihiro Suda <suda.akihiro@lab.ntt.co.jp>
This allows Go to build third party packages correctly without vendoring
issues what want to create their own SpecOpts.
Fixes#2289
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
In a few places we check for nil types when modifying a spec,
but in many cases we do not so we could get a panic if the
passed in type was not filled. Because the generated spec is
filled we will not notice this but users may get unexpected
panics.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
