[PATCH v2] security, fs, nfs, net: update security_inode_listsecurity() interface

Stephen Smalley stephen.smalley.work at gmail.com
Fri Jun 6 14:28:02 UTC 2025


On Fri, Jun 6, 2025 at 9:38 AM Konstantin Andreev <andreev at swemel.ru> 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@gmail.com/
>
> 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.



More information about the Linux-security-module-archive mailing list