Vendoring /etc/apparmor* into snapd still sounds a bit problematic - the question would be then which aa2 version to vendor - and ideally to avoid a mismatch between the parser and profiles we would still want to vendor apparmor_parser into snapd then too.
For completeness, Jamie also suggested on IRC that we could bind-mount the parser from the host into the snap - in this case, there is still an open question of whether we always do this, or just when the multipass- support/docker-support interface is connected. I would think that perhaps it makes most sense to only do this in the interface support code. This last option seems the easiest quick fix since it does not require updates to the base snaps and it doesn't have much chance of regression (compared to using the apparmor config/profiles of the base snaps) since we are already using this (host) policy for these interfaces. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1898038 Title: docker-support/multipass-support broken with system apparmor3 (20.10) To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1898038/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
