On Fri, Jun 23, 2023 at 11:31:04AM -0600, Jim Fehlig wrote: > On 6/23/23 07:11, Andrea Bolognani wrote: > > However, not only you've added a few such statements in your recent > > commit 9b743ee19053, but I myself have done the same a couple months > > back with commit 7a39b04d683f, as part of enabling passt support. So > > in a way we've already started depending on AppArmor 3.0, in open > > contrast with our platform support policy. > > > > I'm quite unclear on the best way forward :( > > I'd prefer to defer support for local customizations of abstractions until > upstream libvirt can support apparmor >= 3.0. In the meantime commit > 9b743ee19053 can be changed to 'include <local/foo>' since we provide > local/foo. We'd need to drop the include entirely from your commit, and > again defer until upstream supports apparmor >= 3.0. The problem is that passt support won't work if the abstraction is not included, and we can't make the include unconditional in that case. So we'd effectively have to wait two more years to make passt work with AppArmor, which I don't think is acceptable. My best idea at the moment is to make a second copy of the AppArmor profiles targeting 2.x specifically, with a reduced feature set: no passt, no local overrides for abstractions. At build time, we can decide which version of the profiles to install based on the AppArmor version detected on the system. It wouldn't be pretty, but it would get us out of the current situation without modern distros having to sacrifice anything and without causing issues for older distros. In two years, we can drop the additional stuff and go back to a more sane state. What do you think? -- Andrea Bolognani / Red Hat / Virtualization
