On Fri, Jun 6, 2025 at 9:38 AM Konstantin Andreev <andreev@xxxxxxxxx> wrote: > > Stephen Smalley, 28/04/2025: > > Update the security_inode_listsecurity() interface to allow > > use of the xattr_list_one() helper and update the hook > > implementations. > > > > Link: https://lore.kernel.org/selinux/20250424152822.2719-1-stephen.smalley.work@xxxxxxxxx/ > > Sorry for being late to the party. > > Your approach assumes that every fs-specific xattr lister > called like > > | vfs_listxattr() { > | if (inode->i_op->listxattr) > | error = inode->i_op->listxattr(dentry, list, size) > | ... > > must call LSM to integrate LSM's xattr(s) into fs-specific list. > You did this for tmpfs: > > | simple_xattr_list() { > | security_inode_listsecurity() > | // iterate real xatts list > > > Well, but what about other filesystems in the linux kernel? > Should all of them also modify their xattr listers? > > To me, taking care of security xattrs is improper responsibility > for filesystem code. > > May it be better to merge LSM xattrs > and fs-backed xattrs at the vfs level (vfs_listxattr)? This patch and the preceding one on which it depends were specifically to address a regression in the handling of listxattr() for tmpfs/shmem and similar filesystems. Originally they had no xattr handler at the filesystem level and vfs_listxattr() already has a fallback to ensure inclusion of the security.* xattr for that case. For filesystems like ext4 that have always (relative to first introduction of security.* xattrs) provided handlers, they already return the fs-backed xattr value and we don't need to ask the LSM for it. That said, you may be correct that it would be better to introduce some additional handling in vfs_listxattr() but I would recommend doing that as a follow-up.
