Ok, so that's an apparmor or apparmor profile problem.
LXD recently changed to also allow for apparmor profiles to be loaded
inside privileged containers. This seems to align with your timeline
above.
Before that change, your kvm process wasn't itself confined when run
inside a privileged LXD container, instead only being confined by the
container's own profile. With this LXD fix, we now offer the same
behavior for unprivileged and privileged containers, letting the
container load its own profile in both cases.
There are a number of problems with apparmor profiles being loaded as
part of an apparmor stack not behaving the same as when loaded in the
host, but those are either issues that need be addressed in the profiles
or in the apparmor kernel code.
As far as we (LXD) are concerned, we'd very much appreciate it if
apparmor could behave the same in containers as it does on the host, but
we understand that there are design problems with this and so most
apparmor profiles are now showing some problems...
Closing LXD task as invalid, since as far as LXD is concerned, we are
doing the right thing wrt apparmor setup. This is caused by either
apparmor misbehaving or the apparmor profile being invalid.
** Changed in: lxd (Ubuntu)
Status: New => Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1684481
Title:
KVM guest execution start apparmor blocks on /dev/ptmx now
(regression?)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1684481/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
