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 <[email protected]> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
