Re: [PATCH 1/4] xfs: hide private inodes from bulkstat and handle functions

From: "Darrick J. Wong" <djwong@kernel.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH 1/4] xfs: hide private inodes from bulkstat and handle functions
Date: Wed, 28 Feb 2024 08:52:27 -0800	[thread overview]
Message-ID: <20240228165227.GH1927156@frogsfrogsfrogs> (raw)
In-Reply-To: <Zd4mxB5alRUsAS7o@infradead.org>

On Tue, Feb 27, 2024 at 10:15:32AM -0800, Christoph Hellwig wrote:
> On Mon, Feb 26, 2024 at 06:24:46PM -0800, Darrick J. Wong wrote:
> > Callers are not allowed to link these
> > files into the directory tree, which should suffice to make these
> > private inodes actually private.
> 
> I'm a bit confused about this commit log.  The only files with
> i_nlink == 0 that can be linked into the namespace or O_TMPFILE
> files that have I_LINKABLE.
> 
> The only think that cares about S_PRIVATE are the security modules
> (and reiserfs for it's own xattr inodes).
> 
> So I think setting the flag is a good thing and gets us out of nasty
> interaction with LSMs, but the commit log could use a little update.

How about:

"We're about to start adding functionality that uses internal inodes
that are private to XFS.  What this means is that userspace should never
be able to access any information about these files, and should not be
able to open these files by handle.

"Callers must not be allowed to link these files into the directory
tree, which should suffice to keep these private inodes actually
private.  I_LINKABLE is therefore left unset.

"To prevent mis-interactions with LSMs, and the rest of the security
apparatus, set S_PRIVATE."

--D