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=fB17Y/th; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTPS id 097F35A004E for ; Tue, 13 Jan 2026 23:25:31 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1768343131; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=jxBvvI5xHw4fD2SvCC0ZPkiYmXTzvpgNQEeho56PT8w=; b=fB17Y/thWrIzDyRALMnHEhw5L3NSswsTIe0K119nwObC8LPwvEQVNkA8+8y+qKW75rr0qG XzjlIvY7hKBui/xc/W3DrwQn5CfamVffu2f0lfF93EvIHEW3GykgoHBKMhxPE/1eriE+SA J4LZcDpIWAFserrczEuToRVkJmln/+s= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-152-kW88Qm0SMz6fa0QS1rL8Ug-1; Tue, 13 Jan 2026 17:25:29 -0500 X-MC-Unique: kW88Qm0SMz6fa0QS1rL8Ug-1 X-Mimecast-MFC-AGG-ID: kW88Qm0SMz6fa0QS1rL8Ug_1768343128 Received: by mail-wr1-f72.google.com with SMTP id ffacd0b85a97d-42fb1c2c403so5887359f8f.3 for ; Tue, 13 Jan 2026 14:25:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768343128; x=1768947928; h=content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=jxBvvI5xHw4fD2SvCC0ZPkiYmXTzvpgNQEeho56PT8w=; b=MiVWCZLmdM5EdSegANUWyXYfDJR4J2DV1HRz1vg6cknpnUhdtWM1lz9Zbf6Ss2oRdO dwLRjidQVi9yw+Vz35THNPkwTut0EWHKsrOrK7aFzMLjgbmLkG1Zo5hv8/MRoK4pl0m0 hj/nU/qKrOl0L4LQO//L1IMCW+d+Wp5g1RGNX0tguhgATrpI+xfrGp/I1ikI7V8a87YO 9fXL8PQigHORchpJbFQuhlY8mNGCWRedlx/o2UIDRAoK93HMceu9KhYlv+UBS9uoGmVm TptcMti67xg8T2sIRnQ/GC+fAsRiOy8T9Da21JeOSNPYL6TUjpHeeYx9YGQQM5MzG2kJ OJMg== X-Gm-Message-State: AOJu0YyTorNyZDhhcKZPr7qrJVhr2LhAs9MOcO9PMNAbHMaeIHb8pq17 LGf/WMkwYV/W3Uj/zagAkbAU0KEbIC74+M+kveL3FVmPI51Fb2nO0IU7+mbqfstlf5QEZN/lGjO 7J3g2eI6npq8EdCEY4EwcuiK9oeyWXEHOUaz9loL6ijNx9/tQMILymw== X-Gm-Gg: AY/fxX4u10DdNqlScdcfXJ8O3GjrkSbu5/Gy/kG02l09VjCuyJe9PRsc1dDr6eUX7jM lIzIhCBpa6g3/2p65z9QX4vso/LDzHNXxooGZs+1KEGmBhGxnwr5JNyfM6jyd8p7aBi6c1yw5sb x6uwOmpbpsblgVKWM+3tAIcgfBGhXFO0/DGnpub1iakN/v0OIGvHrX8ihtr09lq8/7yC/maEAXp DGWTR0AMdPXDx1iB8MqPXq8gjVHcoS5umJ3KbXsAnzK0IhBSuwcEb8NhlzBI52vVKrtQruC1mqX QgwDDcYpu9d26Cs2GaxyONzGCbHrGn8s6o8DD4SDi6mrm7xdu9IpPCO2a1lZjt/zo+lLBvvVmID 1nN3aWpCsUIKLmfpAknGP X-Received: by 2002:a05:6000:1ac8:b0:431:266:d135 with SMTP id ffacd0b85a97d-4342d5cf43fmr30215f8f.52.1768343128305; Tue, 13 Jan 2026 14:25:28 -0800 (PST) X-Received: by 2002:a05:6000:1ac8:b0:431:266:d135 with SMTP id ffacd0b85a97d-4342d5cf43fmr30193f8f.52.1768343127899; Tue, 13 Jan 2026 14:25:27 -0800 (PST) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [2a10:fc81:a806:d6a9::1]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd5ee24esm46200259f8f.33.2026.01.13.14.25.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 13 Jan 2026 14:25:27 -0800 (PST) Date: Tue, 13 Jan 2026 23:25:24 +0100 From: Stefano Brivio To: Andrea Bolognani Subject: Re: [PATCH] apparmor: Upgrade ABI version to 4.0, explicitly enable user namespace creation Message-ID: <20260113232524.1a67714e@elisabeth> In-Reply-To: References: <20260110151430.3668869-1-sbrivio@redhat.com> <20260112184607.5d0978a0@elisabeth> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.49; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: ps93p2R5vSfOhjZb1hAtNeeY1puyHh5LsLODSnVuyE8_1768343128 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: L64Z7VJQVGJLTJ4FW24AMCSS5B2BO2HG X-Message-ID-Hash: L64Z7VJQVGJLTJ4FW24AMCSS5B2BO2HG X-MailFrom: sbrivio@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 , Maxime =?UTF-8?B?QsOpbGFpcg==?= , 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 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