The automatic installation of AppArmor policies prevents the
management of custom, site-specific apparmor policies for the
default container profile. Furthermore, this change will allow
a future policy for the engine itself to be written without demanding
the engine be able to arbitrarily create and manage AppArmor policies.
- Add deb package suggests for apparmor.
- Ubuntu postinst use aa-status & fix policy path
- Add the policies to the debian packages.
- Add apparmor tests for writing proc files
Additional restrictions against modifying files in proc
are enforced by AppArmor. Ensure that AppArmor is preventing
access to these files, not simply Docker's configuration of proc.
- Remove /proc/k?mem from AA policy
The path to mem and kmem are in /dev, not /proc
and cannot be restricted successfully through AppArmor.
The device cgroup will need to be sufficient here.
- Load contrib/apparmor during integration tests
Note that this is somewhat dirty because we
cannot restore the host to its original configuration.
However, it should be noted that prior to this patch
series, the Docker daemon itself was loading apparmor
policy from within the tests, so this is no dirtier or
uglier than the status-quo.
Signed-off-by: Eric Windisch <eric@windisch.us>
Upstream-commit: 80d99236c1ef9d389dbaca73c1a949da16b56b42
Component: engine
As suggested in https://github.com/docker/docker/pull/14004/files#r34022527
The concern there is we can't differentiate whether user explicitly
asked for an invalid value of -1 or he did not specify anything.
I don't think this would be a problem, because:
- like all other default values like zero, we can't differentiate
user specify it or not, most of which, zeros are also invalid, so
default is default, we show these default values in help info,
so users would know if they set value as default, it'll be like
they set nothing.
- we can't do this kind of string check in REST api request, so
it'll make the behave different from docker command and RESTapi.
Signed-off-by: Qiang Huang <h.huangqiang@huawei.com>
Upstream-commit: 6f8ddec1d0e67058c7a4a15c7d4d9a75bc1e5dea
Component: engine
The check for the end of the loop was off by one which is why we saw
errors on the following inpsect() call instead of a timeout
Signed-off-by: Doug Davis <dug@us.ibm.com>
Upstream-commit: c5c98c31a184837c7f5b1f43d8ef18a676a8bf30
Component: engine
Replaced github.com/docker/libcontainer with
github.com/opencontainers/runc/libcontaier.
Also I moved AppArmor profile generation to docker.
Main idea of this update is to fix mounting cgroups inside containers.
After updating docker on CI we can even remove dind.
Signed-off-by: Alexander Morozov <lk4d4@docker.com>
Upstream-commit: c86189d554ba14aa04b6314970d3699e5ddbf4de
Component: engine
Check if there is a plugin socket first under `/run/docker/plugins/NAME.sock`.
If there is no socket for a plugin, check `/etc/docker/plugins/NAME.spec` and
`/usr/lib/docker/plugins/NAME.spec` for spec files.
Signed-off-by: David Calavera <david.calavera@gmail.com>
Upstream-commit: 6c0795747b00589641eb34eb7adce05a56d8840f
Component: engine
Memory swappiness option takes 0-100, and helps to tune swappiness
behavior per container.
For example, When a lower value of swappiness is chosen
the container will see minimum major faults. When no value is
specified for memory-swappiness in docker UI, it is inherited from
parent cgroup. (generally 60 unless it is changed).
Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Upstream-commit: 921da495d24695dda66d3f58e78887dd0bc2402e
Component: engine
Carry #11675
Aside from what #11675 says, to me a key usecase for this is to support
more than one Docker cli running at the same time but each may have its
own set of config files.
Signed-off-by: Doug Davis <dug@us.ibm.com>
Upstream-commit: daced1d30345aca06857f874dfb48b7e90cb409b
Component: engine
This is a follow-on to PR #14520.
PR #14520 is the quick fix to get the testing working again.
This PR makes sure that the list of execs associated with a container goes
from zero to one (as a new exec is run), then back to zero when the exec is
finished. However, we should be able to query the exec while the container
is still around, and even though the exec isn't listed in the container's
inspect data.
Signed-off-by: Doug Davis <dug@us.ibm.com>
Upstream-commit: 72b75cd4e764e25cecd3f0c100597b8868c68120
Component: engine
Libcontainer already supported mount container's own cgroup into
container, with this patch, we can see container's own cgroup info
in container.
Signed-off-by: Qiang Huang <h.huangqiang@huawei.com>
Upstream-commit: f18fb5b3efd59d54c00d4e1b1d4b88c4b21e96be
Component: engine
