Control: tag -1 - upstream
Control: tag -1 + moreinfo
Hi,
kaka:
> Over the year, if I enable apparmor for lxc (lxc.aa_profile =
> lxc-container-default),
First, I don't think you need to turn this on manually and I doubt
this is the best AppArmor profile to use. According to
lxc.container.conf(5):
APPARMOR PROFILE
If lxc was compiled and installed with apparmor support, and the host
sys‐
tem has apparmor enabled, then the apparmor profile under which the
con‐
tainer should be run can be specified in the container configuration.
The
default is lxc-container-default-cgns if the host kernel is cgroup
names‐
pace aware, or lxc-container-default othewise.
So not setting lxc.aa_profile at all should automatically select the
lxc-container-default-cgns profile. Not that it would make
a difference for this bug though.
> I see a lot of "apparmor denied" messages like below,
> But the lxc itself is can running and functional without a problem,
> Why apparmor always complain lxc? (is this normal)?
> apparmor="DENIED" operation="mount" info="failed type match" error=-13
> profile="lxc-container-default" name="/sys/fs/pstore/" pid=2676 comm="mount"
> fstype="pstore" srcname="pstore"
> apparmor="DENIED" operation="mount" info="failed type match" error=-13
> profile="lxc-container-default" name="/sys/fs/pstore/" pid=2676 comm="mount"
> fstype="pstore" srcname="pstore" flags="ro"
> apparmor="DENIED" operation="mount" info="failed flags match" error=-13
> profile="lxc-container-default" name="/" pid=2763 comm="mount" flags="rw,
> remount"
On current sid:
- I cannot reproduce this with the lxc-debian template, which is
expected since it has no lxc.mount.entry for /sys/fs/pstore
- I cannot reproduce this with the lxc-ubuntu template (which _has_
a lxc.mount.entry for /sys/fs/pstore) either:
# lxc-create -n ubuntu -t /usr/share/lxc/templates/lxc-ubuntu
[…]
# lxc-start -F -n ubuntu
[…]
Ubuntu 16.04.5 LTS ubuntu console
ubuntu login: ubuntu
Password:
[…]
$ ubuntu@ubuntu:~$ mount | grep pstore
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
And there's no single AppArmor denial in the host system's logs.
aa-status confirms that this container is running under the
lxc-container-default-cgns profile.
So, can you still reproduce this on current testing/sid?
If yes, can you please share a simple reproducer similar to the one
I've tried to provide above?
Cheers,
--
intrigeri
