Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Bug#989781: docker.io: Docker fails to run containers because it unsuccessfully tries to load an AppArmor profile

381 views
Skip to first unread message

Lars Veldscholte

unread,
Jun 12, 2021, 6:40:04 PM6/12/21
to
Package: docker.io
Version: 20.10.5+dfsg1-1+b3
Severity: important

Dear Maintainer,

After installing docker.io on a Debian machine with a 'default'
AppArmor installation, I am unable to run containers. The error message
I get is as follows:

Error response from daemon: AppArmor enabled on system but the docker-default profile could not be loaded: running `apparmor_parser apparmor_parser --version` failed with output:
error: exec: "apparmor_parser": executable file not found in $PATH

It appears that Docker tries to load an AppArmor profile, but fails to
do so because I do not have the AppArmor userspace utilities installed,
because I am not actually using AppArmor (nor do I intend to). However,
because AppArmor is included/enabled in the kernel shipped by Debian by
default, Docker thinks it needs to load a profile.

I am not sure of the proper way to deal with this issue. Should I
install the AppArmor userspace utilities, even though I do not need them
myself? Or should I disable AppArmor completely by explicity setting a
kernel parameter (which the Debian wiki does not recommend)?

In the former case, docker.io should probably depend on the apparmor
package (it is currently a recommendation), since Docker is not usable
(as far as I understand) without it.

Thanks in advance,

Lars

-- System Information:
Debian Release: 11.0
APT prefers testing-security
APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-2-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages docker.io depends on:
ii adduser 3.118
ii containerd 1.4.5~ds1-1+b2
ii init-system-helpers 1.60
ii iptables 1.8.7-1
ii libc6 2.31-12
ii libdevmapper1.02.1 2:1.02.175-2.1
ii libsystemd0 247.3-5
ii lsb-base 11.1.0
ii runc 1.0.0~rc93+ds1-5+b1
ii tini 0.19.0-1

Versions of packages docker.io recommends:
pn apparmor <none>
ii ca-certificates 20210119
pn cgroupfs-mount <none>
ii git 1:2.30.2-1
ii needrestart 3.5-4
ii xz-utils 5.2.5-2

Versions of packages docker.io suggests:
pn aufs-tools <none>
ii btrfs-progs 5.10.1-2
pn debootstrap <none>
pn docker-doc <none>
ii e2fsprogs 1.46.2-1
pn rinse <none>
pn rootlesskit <none>
ii xfsprogs 5.10.0-4
pn zfs-fuse | zfsutils-linux <none>

-- no debconf information

Tianon Gravi

unread,
Jun 14, 2021, 4:40:03 PM6/14/21
to
On Sat, 12 Jun 2021 at 15:33, Lars Veldscholte <la...@tuxplace.nl> wrote:
> I am not sure of the proper way to deal with this issue. Should I
> install the AppArmor userspace utilities, even though I do not need them
> myself? Or should I disable AppArmor completely by explicity setting a
> kernel parameter (which the Debian wiki does not recommend)?

If you don't completely disable AppArmor but also do not install the
userspace utilities, you will always be in this halfway state where
AppArmor *is* enabled, but most programs won't be able to use/deal
with it effectively.

If you really want to avoid AppArmor completely, I would suggest
actually disabling it, although just installing the userspace
utilities will allow your containers to benefit from AppArmor-based
protections -- it's another layer of protection (and my experience
using the Debian implementation of AppArmor on both desktop and server
systems is that it stays out of the way pretty well).

> In the former case, docker.io should probably depend on the apparmor
> package (it is currently a recommendation), since Docker is not usable
> (as far as I understand) without it.

Looking at [1], Recommends: is definitely appropriate here:

| This declares a strong, but not absolute, dependency.
|
| The Recommends field should list packages that would be found
together with this one in all but unusual installations.

[1]: https://www.debian.org/doc/debian-policy/ch-relationships.html#binary-dependencies-depends-recommends-suggests-enhances-pre-depends

♥,
- Tianon
4096R / B42F 6819 007F 00F8 8E36 4FD4 036A 9C25 BF35 7DD4
0 new messages