From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: passt.top; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=gZbeBu+3; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by passt.top (Postfix) with ESMTPS id 3D1B05A004E for ; Tue, 13 Jan 2026 14:06:49 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1768309608; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=tlJlfqNr5nSnL4K4d8QKQYtcCkCtCm7nUb+BfG8hxLI=; b=gZbeBu+3Lkw72bIW0hEFWUQAj80jEhPcU0CH5mHu0Dy4M2fQ0t527OUvrhf31obqcmZGQE hyNae2Nyg+3CO9iaGiFFwoRmgCVUwQAmg1nsE1qSoIpfaglXDPr+Qgx5wLWoMJ+n80XcWC rikcTSELSX2bjLD/vpUvDYshTgCwXso= Received: from mail-ej1-f71.google.com (mail-ej1-f71.google.com [209.85.218.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-421-eENeTgQMPJSaEHgw58UQ6A-1; Tue, 13 Jan 2026 08:06:46 -0500 X-MC-Unique: eENeTgQMPJSaEHgw58UQ6A-1 X-Mimecast-MFC-AGG-ID: eENeTgQMPJSaEHgw58UQ6A_1768309605 Received: by mail-ej1-f71.google.com with SMTP id a640c23a62f3a-b83c3dd2092so984187366b.1 for ; Tue, 13 Jan 2026 05:06:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768309605; x=1768914405; h=cc:to:subject:message-id:date:in-reply-to:mime-version:references :from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=tlJlfqNr5nSnL4K4d8QKQYtcCkCtCm7nUb+BfG8hxLI=; b=A02WhSWIC4xFgqF1qTdwOQaVthuib+Asqzem4ZyQbRBdsG0IcmBBRs3rTxRQlQN3Ek Pfcu7u8JmBk1IyMrob1+JzSqAbjV9g5APj9OGNZqMmzH+ytN5FsnPomzSd3C1FK7Snyk hMYl6wGd6EhI/sSkAzGJLe3NWwodcPkWM9VIKHln9AIHG5OClmvwjPemO6jgsgvoWKmS YpKx+RetprqrYjdg+JilmJpJy6i5Sw2dOgdeOQy9R+nhbzoSg/9RcTEl1Ffu95Ppm8yj zPsX9tTVuJMFUIL64gz8LbwAuARVYdHzNaVkD3HRUSmqfaOmaIrfYCDh8ZD5VY2u7BLV hPjw== X-Gm-Message-State: AOJu0Yxw8Rcu7F0o/zjMojnxY7RT3mnMs8ixMmnTyGJjuW7JMRLvR+KX Qzije/QAQux73zkyLwfe7pdUQyHRr9SxfEccE0z7nCBg/tshvfRzquUviXiw4hHnjV1+vI/1d51 6CO1AdNX60hZm1HhBJtHAtjvffxMx6nmkS4YTvJL8DL+6oJHCKpvUX89fKEqEZ6GdwVjkN4nJq7 gXXLRFh6b27C+OLPeA28jySSt17NsL X-Gm-Gg: AY/fxX7WcvfZgawuE+edrS/fA9mBb7a91e62y1X/RjQecNbhV6FGcxugFPo+hemLbRG auyr3dvTiY97Djvd5Y/5u5NP60pkrGp79KcWx7ZXxuE4qNmaph6jeJb7UdqQFK91UIR6wPJHZ86 DVKjFNwRfOJ/NLwr3bSilgFJ8+LNPpxP4wYcvPtt+cYkWpEVpbGgqUwADv+BdSFpSq X-Received: by 2002:a17:907:a089:b0:b87:1ffc:bfbc with SMTP id a640c23a62f3a-b871ffcc395mr561848266b.12.1768309605420; Tue, 13 Jan 2026 05:06:45 -0800 (PST) X-Google-Smtp-Source: AGHT+IFd/dZLjswZDSK44sNKN4WBBrNU4RYvFSccnF5Lvjg/7iulTzjaMJtkIEEgYJiuDoPly3ddcytk2D73eerp+Vc= X-Received: by 2002:a17:907:a089:b0:b87:1ffc:bfbc with SMTP id a640c23a62f3a-b871ffcc395mr561845566b.12.1768309604904; Tue, 13 Jan 2026 05:06:44 -0800 (PST) Received: from 744723338238 named unknown by gmailapi.google.com with HTTPREST; Tue, 13 Jan 2026 05:06:41 -0800 Received: from 744723338238 named unknown by gmailapi.google.com with HTTPREST; Tue, 13 Jan 2026 05:06:41 -0800 From: Andrea Bolognani References: <20260110151430.3668869-1-sbrivio@redhat.com> <20260112184607.5d0978a0@elisabeth> MIME-Version: 1.0 In-Reply-To: <20260112184607.5d0978a0@elisabeth> Date: Tue, 13 Jan 2026 05:06:41 -0800 X-Gm-Features: AZwV_Qhy9NgTgA-_IiNN7JsYZq5umFKfNfKG0XcOSM4R5tM-5hgEYtr7m6aTwKY Message-ID: Subject: Re: [PATCH] apparmor: Upgrade ABI version to 4.0, explicitly enable user namespace creation To: Stefano Brivio X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: PC8NGm5-oheG2nyMWHD8AHGuqLkc8EBv4FPYBv7ySqA_1768309605 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Message-ID-Hash: YKI5HGU2V2WMMLFBDX2SYFW6ZXCWDNQM X-Message-ID-Hash: YKI5HGU2V2WMMLFBDX2SYFW6ZXCWDNQM X-MailFrom: abologna@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: passt-dev@passt.top, Niklas Edmundsson , Jim Fehlig , =?UTF-8?Q?Maxime_B=C3=A9lair?= , Dario Faggioli , devel@lists.libvirt.org X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: 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. > > 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 :) -- Andrea Bolognani / Red Hat / Virtualization