Re: [PATCH] apparmor: Upgrade ABI version to 4.0, explicitly enable user namespace creation

On Tue, 13 Jan 2026 05:06:41 -0800 Andrea Bolognani 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 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