On Tue, 13 Jan 2026 05:06:41 -0800 Andrea Bolognani <[email protected]> wrote:
> On Mon, Jan 12, 2026 at 06:46:07PM +0100, Stefano Brivio wrote: > > On Mon, 12 Jan 2026 08:11:44 -0700 Andrea Bolognani <[email protected]> > > wrote: > > > > > [adding libvirt devel list] > > > > > > On Sat, Jan 10, 2026 at 04:14:30PM +0100, Stefano Brivio wrote: > > > > In the 3.0 AppArmor ABI version we currently use, user namespace rules > > > > are not supported, and, as long as we load confined profiles, those > > > > implicitly allow creation of user namespaces. > > > > > > > > However, ABI version 4.0 introduces rules for user namespaces, and if > > > > we don't specify any, we can't create user namespaces, see: > > > > > > > > > > > > https://gitlab.com/apparmor/apparmor/-/wikis/unprivileged_userns_restriction > > > > > > > > This wouldn't affect us in general, given that we're using the 3.0 > > > > ABI, but libvirt's policy uses 4.0 instead, and if our abstractions > > > > are used from there, no matter what ABI policy version we declare, > > > > rules for user namespace creation now match ABI policy version 4.0. > > > > > > AFAICT libvirt's policy doesn't explicitly declares any ABI version, > > > so how does that work? Is the most recent one being used in that > > > case? > > > > Oh, right, I forgot to mention that this is implicit from including > > abstraction/base in libvirt's policy, which uses 4.0 on all the current > > versions of AppArmor-enabled distributions I checked (Debian, including > > stable/trixie, Ubuntu, openSUSE). > > Got it. > > Note that libvirt still targets Debian 12 too, and that's stuck with > AppArmor 3. Same for Ubuntu 22.04, though that one is getting dropped > from our support matrix in just a few months. Ah, thanks for the information. But anyway I don't plan to backport this change to anything before trixie, so I don't think there should be any problem with it. > > > Do we want to make the ABI version explicit in libvirt's policy? If > > > so, should we stick with 3.0 for maximum compatibility? > > > > I wouldn't make it explicit. Yes, sticking to 3.0 would have avoided > > this issue and resulted in better compatibility overall but would cause > > even more problems if you ever need to switch "back" to 4.0 at some > > point in time. > > > > I think that using the version from abstraction/base as libvirt does > > is actually a more convenient and compatible approach in general. > > > > We didn't do that in passt's policy because the rules included there > > are too broad, but given that libvirtd's policy already includes it, > > I'd suggest to keep it that way. > > That sounds good, especially given the OS support constraints > mentioned above. > > Nothing to be done on the libvirt side then! That's perfect :) Cheers. :) -- Stefano
