[pkg-lxc-devel] Bug#947863: lxc: apparmor denied mount with unprivileged lxc

[Harald Welte]

I'm seeing this problem all the time when using a pretty default Debian buster
host with Debian buster lxc containers.

If you then use the standard Debian 'certbot' package inside the lxc container,
it will fail to be executed every time:

Host:
[15500835.942037] audit: type=1400 audit(1594975170.691:971): apparmor="DENIED" operation="mount" info="failed flags match" error=-13 profile="lxc-container-default-cgns" name="/" pid=20567 comm="(certbot)" flags="rw, rslave"

LXC:
Jul 17 10:39:30 people systemd[5522]: certbot.service: Failed to set up mount namespacing: Permission denied
Jul 17 10:39:30 people systemd[5522]: certbot.service: Failed at step NAMESPACE spawning /usr/bin/certbot: Permission denied


Isn't 'debian 10 lxc container' inside 'debian 10 host' something that should
work out of the box, both for privileged and unprivileged containers?  And isn't the
use of certbot pretty much the most common thing to do for any machine exposing https
to the internet today?

I guess what triggers all of this is the PrivateTmp=true in certbot.service?

In any case, this problem seems to be around for more than 1.5 years by now,
with various ugly workarounds in existance.

* https://github.com/lxc/lxc/pull/2758
* https://github.com/lxc/lxc/issues/2778
* Ubuntu patched systemd to ignore setting up namespaces: https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=030919ba5e4931d6ee576d0259fae67fe4ed9770

In the end, I agree with josch's comment: If unprivileged containers are not
expected to run with apparmor at all, then why does the default config not
disable that?

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)