On Wed, Feb 28, 2024 at 09:02:30AM -0800, Christoph Hellwig wrote: > On Wed, Feb 28, 2024 at 08:52:27AM -0800, Darrick J. Wong wrote: > > 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. > > I_LINKABLE is only set for O_TMPFILE, so I wouldn't even bother with > that. But thinking about this: what i_nlink do these private inodes > have? If it is >= 1, we probably want to add an IS_PRIVATE check > to xfs_link just in case they ever leak out to a place where ->link > could be called. Ooh, that's a good catch. I'll check for IS_PRIVATE in xfs_vn_link. "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. "To prevent userspace from ever finding the file, or mis-interactions with the security apparatus, set S_PRIVATE on the inode. Don't allow bulkstat, open-by-handle, or linking of S_PRIVATE files into the directory tree. This should keep private inodes actually private." --D
