Add HostConfig.Umask and pass it to the OCI process spec for container
entrypoints, exec processes, and healthchecks.
Preserve the configured umask when exec user resolution reconstructs the
OCI User value, so runtimes receive it in the per-exec process spec.
Keep the field aligned with OCI's uint32 representation - raw JSON
clients need to use 18 for octal 0022 for example.
Co-authored-by: Youfu Zhang <zhangyoufu@gmail.com>
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
This is a long-requested feature, and it solves several usability
problems with the default AppArmor profile:
1. The profile is completely opaque because we don't write to
/etc/apparmor.d anymore -- this leads to lots of headaches when
trying to run certain semi-privileged programs inside containers.
It's much nicer to be able to have a starting point for a custom
AppArmor profile.
2. Changes to AppArmor have broken backwards compatibility in the past
(leading to containers not working properly) -- the poster-child for
this problem was signal mediation. In order to fix this problem,
distributions had to patch Docker when it would've been much nicer
to provide a hotfix in the form of a custom configuration they could
apply to their hosts.
It also bridges the feature gap between the default seccomp profile
(which has been configurable for a very long time). This patch also
fixes a few minor bugs in the AppArmor profile implementation (notably,
Docker would not forcefully load its built-in profile at start time --
meaning a Docker update wouldn't actually update the profile).
This feature should probably be ported to other container runtimes
(containerd, podman/cri-o, etc) so that we can continue with the effort
to merge all of the disparate AppArmor profile implementations. Ideally
they would all use the same template variables too.
Signed-off-by: Aleksa Sarai <asarai@suse.de>
---
The above was reapplied from the original commit on top of the current
daemon code.
The daemon already force-loads the default AppArmor profile at startup,
so this change wires the configured template into that existing reload
path instead of introducing the reload behavior itself.
The built-in profile now lives in github.com/moby/profiles/apparmor, so
the custom template data follows the current profile variables.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
The daemon upgrades do not restart the kernel, so after a daemon upgrade
the old "docker-default" AppArmor profile remains loaded in the kernel.
The previous code checked IsLoaded and skipped installation if the
profile already existed, which meant that profile template updates
(e.g., from a moby/profiles dependency bump) were never applied until
the next kernel restart.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
These comments were added to enforce using the correct import path for
our packages ("github.com/docker/docker", not "github.com/moby/moby").
However, when working in go module mode (not GOPATH / vendor), they have
no effect, so their impact is limited.
Remove these imports in preparation of migrating our code to become an
actual go module.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Kept `coci` import alias since we use it elsewhere,
maybe to prevent confusion with our own `oci` package.
Signed-off-by: Laura Brehm <laurabrehm@hey.com>
The containerdCli was somewhat confusing (is it the CLI?); let's rename
to make it match what it is :)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Ensure data-race-free access to the daemon configuration without
locking by mutating a deep copy of the config and atomically storing
a pointer to the copy into the daemon-wide configStore value. Any
operations which need to read from the daemon config must capture the
configStore value only once and pass it around to guarantee a consistent
view of the config.
Signed-off-by: Cory Snider <csnider@mirantis.com>
This change makes is possible to run `docker exec -u <UID> ...` when the
containerd integration is activated.
Signed-off-by: Djordje Lukic <djordje.lukic@docker.com>
The containerd client is very chatty at the best of times. Because the
libcontained API is stateless and references containers and processes by
string ID for every method call, the implementation is essentially
forced to use the containerd client in a way which amplifies the number
of redundant RPCs invoked to perform any operation. The libcontainerd
remote implementation has to reload the containerd container, task
and/or process metadata for nearly every operation. This in turn
amplifies the number of context switches between dockerd and containerd
to perform any container operation or handle a containerd event,
increasing the load on the system which could otherwise be allocated to
workloads.
Overhaul the libcontainerd interface to reduce the impedance mismatch
with the containerd client so that the containerd client can be used
more efficiently. Split the API out into container, task and process
interfaces which the consumer is expected to retain so that
libcontainerd can retain state---especially the analogous containerd
client objects---without having to manage any state-store inside the
libcontainerd client.
Signed-off-by: Cory Snider <csnider@mirantis.com>
The Linux kernel never sets the Inheritable capability flag to anything
other than empty. Moby should have the same behavior, and leave it to
userspace code within the container to set a non-empty value if desired.
Reported-by: Andrew G. Morgan <morgan@kernel.org>
Signed-off-by: Samuel Karp <skarp@amazon.com>
The runc/libcontainer apparmor package on master no longer checks if apparmor_parser
is enabled, or if we are running docker-in-docker.
While those checks are not relevant to runc (as it doesn't load the profile), these
checks _are_ relevant to us (and containerd). So switching to use the containerd
apparmor package, which does include the needed checks.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Format the source according to latest goimports.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Exec processes do not automatically inherit AppArmor
profiles from the container.
This patch sets the AppArmor profile for the exec
process.
Before this change:
apparmor_parser -q -r <<EOF
#include <tunables/global>
profile deny-write flags=(attach_disconnected) {
#include <abstractions/base>
file,
network,
deny /tmp/** w,
capability,
}
EOF
docker run -dit --security-opt "apparmor=deny-write" --name aa busybox
docker exec aa sh -c 'mkdir /tmp/test'
(no error)
With this change applied:
docker exec aa sh -c 'mkdir /tmp/test'
mkdir: can't create directory '/tmp/test': Permission denied
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
When 567ef8e785 ("daemon: switch to 'ensure' workflow for AppArmor
profiles") was merged, it didn't correctly handle the exec path if
AppArmor profiles were deleted. Fix this by duplicating the
ensureDefaultApparmorProfile code in the exec code.
Fixes: 567ef8e785 ("daemon: switch to 'ensure' workflow for AppArmor profiles")
Signed-off-by: Aleksa Sarai <asarai@suse.de>
The LXC driver was deprecated in Docker 1.8.
Following the deprecation rules, we can remove a deprecated feature
after two major releases. LXC won't be supported anymore starting on Docker 1.10.
Signed-off-by: David Calavera <david.calavera@gmail.com>
