linux-kernel - Re: [PATCH] memfd,selinux: call security_inode_init_security

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <b266fe61-7a7a-b13f-a73c-f30f5edc22a3@google.com>
Date: Tue, 16 Sep 2025 18:08:47 -0700 (PDT)
From: Hugh Dickins <hughd@...gle.com>
To: Thiébaud Weksteen <tweek@...gle.com>
cc: Paul Moore <paul@...l-moore.com>, Hugh Dickins <hughd@...gle.com>, 
    James Morris <jmorris@...ei.org>, 
    Stephen Smalley <stephen.smalley.work@...il.com>, 
    Jeff Vander Stoep <jeffv@...gle.com>, Nick Kralevich <nnk@...gle.com>, 
    Jeff Xu <jeffxu@...gle.com>, Baolin Wang <baolin.wang@...ux.alibaba.com>, 
    linux-kernel@...r.kernel.org, linux-security-module@...r.kernel.org, 
    selinux@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH] memfd,selinux: call security_inode_init_security_anon

On Wed, 17 Sep 2025, Thiébaud Weksteen wrote:
> On Wed, Sep 17, 2025 at 1:26 AM Paul Moore <paul@...l-moore.com> wrote:
> > >
> > > So far as I can tell, seems okay to me:
> > > Acked-by: Hugh Dickins <hughd@...gle.com>
> > >
> > > If I'd responded earlier (sorry), I would have asked for it just to use
> > > &QSTR("[memfd]") directly in the call, rather than indirecting through
> > > unnecessary #define MEMFD_ANON_NAME "[memfd]"; never mind, that's all.
> > >
> 
> Thanks for the review Hugh. In our case, it is necessary to expose
> MEMFD_ANON_NAME as there is a string comparison done in
> security/selinux/hooks.c (see selinux_inode_init_security_anon
> changes).
> I would argue it is cleaner to reference the same constant. The
> alternative here would be to have 2 copies of it, with the risk of
> them being out-of-sync at some point.

Oh, I'm sorry, I simply misread your patch, and thought that the
#define MEMFD_ANON_NAME "[memfd]" came at the start of mm/memfd.c,
whereas it's in include/linux/memfd.h just before mm/memfd.c.

Yes, you're perfectly correct to do it that way then, ignore me.
(I do have to reflect on why three instances of MEMFD_ANON_NAME
are safer than two instances of "[memfd]", but you are correct.)

That does lead me to look quickly at the security/selinux/hooks.c
end of the patch: I don't particularly love what I see there, but
that's none of my business, you and Paul have constraints to meet
there which I'm entirely unfamiliar with.

Hugh