"We could use snap-update-ns to hide the host's /etc if those specific interfaces are connected. We could then present the relevant file from the base snap."
I think hiding all of /etc would be regression prone for existing snaps. We could start to do this in the future if a snap specifies 'base: core22' though. However, expressing what to do with /etc/apparmor and /etc/apparmor.d via the interface code has a few advantages: 1. only multipass-support and docker-support are affected and bind mounts for /etc/apparmor* would be targeted only to these 2. the interface code knows about bases and can specify the etc/apparmor* from the appropriate base 3. snap-confine doesn't need to be adjusted (since snap-update-ns would be handling the mounts) '2' could be simplified by vendoring /etc/apparmor and /etc/apparmor.d into snapd at a predictable location (eg, in usr/lib/snapd/aa2/etc/apparmor and usr/lib/snapd/aa2/etc/apparmor.d (or somewhere)) such that you don't have to search around for the base in use. This would be more predictable and require less coordination for the fix. -- 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 [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
