Looks like the critical point here is loading all the profiles, even when not needed. What can we do here?
a) play with triggers TBD. So far triggers are for "if a file is placed in this directory, run a trigger". Maybe we can have other types, I haven't investigated further. b) disable all profiles What if the opt-in is in two steps: 1) install bin:apparmor.d; 2) enable the profile you are interested in This would also help with the autopkgtests. You would only enable the profile for the app you are going to test. One could argue that the policy is to have everything working right after install. We can come back to this point, but at first, how does the idea sound? c) a stupid idea, but maybe... Could we have a template systemd service for each profile, of the form [email protected], which would load just the specified profile? It would be a oneshot service, which would load just that %i profile (%i in the systemd unit file is how the profile would be referenced). But it would still need to be enabled somehow (can't think of a way to do it automatically when an application is installed), so it's like (b) above. And the existing mechanism to enable/disable a profile is simple enough already. Given that this is meant to be an experimental package, I kind of think (b) would be a good enough compromise. What am I missing? :) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2121409 Title: [FFE] add a new apparmor.d package containing several apparmor profiles To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2121409/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
