From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp-8faa.mail.infomaniak.ch (smtp-8faa.mail.infomaniak.ch [83.166.143.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DC7E4427A0C for ; Thu, 9 Jul 2026 16:05:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=83.166.143.170 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783613120; cv=none; b=ZRgCqv/IBegyH6ooNHudCuN/3FQD7iKtnonP/HR/tbYks5b9T7zxCm3cSBF903deDtyXnRSAOa30aTENp6I0OPacc/lp0zhOaXFiZyfz9YV6BrhBW8MkMQz5WJOTGF2MCggxfijHp0J68Ddb8lzfTqyT1VJCd5zZUPsNY8sbyHs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783613120; c=relaxed/simple; bh=WLMCSNzgVya1yeI6VB6MkC7/cWl4E3NA6H2zOiNlt34=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=LOEKXeA++ElGjGXOK5rL/phm3OfKoC7L9zpOJgKgN43uj1lEJJFpZa6Fjdml8tBT33/Iappp9qFavJHCjf+YO9BMGslxIv14o0zRGiW9AWpW6AA1gRgASHzxmx162MRpRbzaf3FkTmZ2YWEYqKgXDYpaYngiLGMy/T8fkw/1Z+g= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=digikod.net; spf=pass smtp.mailfrom=digikod.net; dkim=pass (1024-bit key) header.d=digikod.net header.i=@digikod.net header.b=UcKgIg2O; arc=none smtp.client-ip=83.166.143.170 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=digikod.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=digikod.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=digikod.net header.i=@digikod.net header.b="UcKgIg2O" Received: from smtp-4-0001.mail.infomaniak.ch (smtp-4-0001.mail.infomaniak.ch [10.7.10.108]) by smtp-3-3000.mail.infomaniak.ch (Postfix) with ESMTPS id 4gx04p3XxVz26g; Thu, 9 Jul 2026 17:58:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digikod.net; s=20191114; t=1783612730; bh=D/YfQO1l9+oQRMO6pfoOvhmNceuKQjV5WSxJDG7oUXo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=UcKgIg2OSQGCZaU15LNI14ytZFUzBtCTaHSLuzhFoVoSLELIpHIKmTWBYZUR3UW2+ EaQjuaB1ss7KuBuDX7hMFHhWj+qIsCAdPpf9a3mUYr6XlivQTjd3z5z40oSxf6Llsm X/uumWaE9Yd8irkRkmX2JcbZ078bT/tyYaHmM2kA= Received: from unknown by smtp-4-0001.mail.infomaniak.ch (Postfix) with ESMTPA id 4gx04m3St2zBWK; Thu, 9 Jul 2026 17:58:48 +0200 (CEST) Date: Thu, 9 Jul 2026 17:58:44 +0200 From: =?utf-8?Q?Micka=C3=ABl_Sala=C3=BCn?= To: Paul Moore Cc: Christian Brauner , =?utf-8?Q?G=C3=BCnther?= Noack , "Serge E . Hallyn" , Daniel Durning , Jonathan Corbet , Justin Suess , Lennart Poettering , Mikhail Ivanov , Nicolas Bouchinet , Shervin Oloumi , Tingmao Wang , kernel-team@cloudflare.com, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org Subject: Re: [PATCH v2 1/9] security: add LSM blob and hooks for namespaces Message-ID: <20260709.paitheut7Ief@digikod.net> References: <3d4fe99cd1665a1be0b36636aeeaf4ab@paul-moore.com> <20260709.kaemaiTia6Li@digikod.net> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Infomaniak-Routing: alpha On Thu, Jul 09, 2026 at 09:03:58AM -0400, Paul Moore wrote: > On Thu, Jul 9, 2026 at 5:12 AM Mickaël Salaün wrote: > > On Wed, Jul 08, 2026 at 11:22:17PM -0400, Paul Moore wrote: > > > On May 27, 2026 =?UTF-8?q?Micka=C3=ABl=20Sala=C3=BCn?= wrote: > > > > > > > > All namespace types now share the same ns_common infrastructure. Extend > > > > this to include a security blob so LSMs can start managing namespaces > > > > uniformly without having to add one-off hooks or security fields to > > > > every individual namespace type. > > ... > > > > > @@ -91,7 +103,10 @@ int __ns_common_init(struct ns_common *ns, u32 ns_type, const struct proc_ns_ope > > > > > > > > void __ns_common_free(struct ns_common *ns) > > > > { > > > > - proc_free_inum(ns->inum); > > > > + security_namespace_free(ns); > > > > + > > > > + if (ns->inum > MNT_NS_INO_SPECIAL_MAX) > > > > + proc_free_inum(ns->inum); > > > > > > The ns->inum check in the if-conditional above isn't quite the same as > > > the is_anon_ns() check it replaces in free_mnt_ns(). You touch on this > > > a bit in the changelog, but that really should be explained in the > > > commit description. > > > > > > ... or honestly, should that change be a separate patch? > > > > I think it's fine, but it's Christian's patch, so I'll let him answer > > and propose a new commit description. > > I don't have a strong opinion on either approach, either a separate > patch or doc update, but one of the two needs to happen. Noted, I'll follow on this with Christian. > > > > > diff --git a/kernel/nsproxy.c b/kernel/nsproxy.c > > > > index d9d3d5973bf5..0f1b208d8eef 100644 > > > > --- a/kernel/nsproxy.c > > > > +++ b/kernel/nsproxy.c > > > > @@ -385,6 +385,12 @@ static int prepare_nsset(unsigned flags, struct nsset *nsset) > > > > > > > > static inline int validate_ns(struct nsset *nsset, struct ns_common *ns) > > > > { > > > > + int ret; > > > > + > > > > + ret = security_namespace_install(nsset, ns); > > > > + if (ret) > > > > + return ret; > > > > + > > > > return ns->ops->install(nsset, ns); > > > > } > > > > > > In the previous revision to the patchset I asked about a > > > security_namespace_switch() hook as we don't know if a namespace is > > > actually attached to a process until we get to switch_task_namespaces(). > > > Perhaps that was answered, but I don't recall reading any mail about that > > > and I'm not able to uncover any responses on lore. > > > > From the cover letter: > > > > no security_namespace_switch() post-hook is > > added in this series: such a hook would only serve LSMs that maintain > > per-task state derived from the active namespace set (SELinux-style > > state tracking), and no current LSM (including this series) needs that. > > Landlock enforces at namespace_install() and namespace_init(), before > > the task-to-nsproxy switch. The hook is left for a separate LSM > > infrastructure proposal once a concrete user emerges. > > > > This follows the guidance of adding new hooks: there must be at least > > one user. > > I'm aware of the new hook guidance, I was the one who documented it :) I know. I guess that means you're ok with that? > > In the future, it's both helpful and polite to reply to the email > asking the question with your response. Adding it to the cover letter > is fine, but to be perfectly honest, once we get past v1 of a > patchset, I don't often read the cover letter very closely unless > there is a significant change. However, I do look back at the > previous posting to ensure all the feedback from everyone has been > either answered or incorporated into the current revision. I forgot to reply to your email, I didn't mean to be impolite, sorry for the inconvenience. It's useful to know that the cover letter is not always part of your review process.