Repository navigation
NAS-144980 / 27.0.0 / statx: report the POSIX ACLs a file has from the inode cache (by yocalebo) - #389
Merged
Conversation
A file server in userspace answers the acl and dacl attributes of NFSv4 and the ACCESS of a file from the mode alone when the file has no POSIX ACL. Finding that out takes a read of system.posix_acl_access for each file, and of system.posix_acl_default for each directory, where nfsd asks get_inode_acl and is answered from the ACLs the inode caches. Add STATX_ACL, which asks vfs_getattr_nosec, on a file system that keeps POSIX ACLs, to look up the access ACL and, for a directory, the default ACL through get_inode_acl, and to set STATX_ATTR_ACL_ACCESS and STATX_ATTR_ACL_DEFAULT for those that exist. The first ask of a cold inode reads each once, and later asks are answered from the cache, which set_cached_acl and forget_cached_acl keep current as ACLs change. A file system keeps no access ACL that the mode already says all of, so one that exists is beyond the mode. Only presence is reported, which listxattr already shows. On an error, or on a kernel without this change, STATX_ACL is left out of stx_mask and the caller reads the ACL as before. A file system that reads its ACLs through ->get_acl alone, such as ecryptfs, answers without it too, since get_inode_acl with no dentry caches no ACL there, which getfacl would then show. Only a caller that asks pays for the lookup. (cherry picked from commit 8bc2de2)
yocalebo
approved these changes
Oct 30, 2026
Author
|
This PR has been merged and conversations have been locked. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A file server in userspace answers the acl and dacl attributes of NFSv4 and the ACCESS of a file from the mode alone when the file has no POSIX ACL. Finding that out takes a read of system.posix_acl_access for each file, and of system.posix_acl_default for each directory, where nfsd asks get_inode_acl and is answered from the ACLs the inode caches.
Add STATX_ACL, which asks vfs_getattr_nosec, on a file system that keeps POSIX ACLs, to look up the access ACL and, for a directory, the default ACL through get_inode_acl, and to set STATX_ATTR_ACL_ACCESS and STATX_ATTR_ACL_DEFAULT for those that exist. The first ask of a cold inode reads each once, and later asks are answered from the cache, which set_cached_acl and forget_cached_acl keep current as ACLs change. A file system keeps no access ACL that the mode already says all of, so one that exists is beyond the mode. Only presence is reported, which listxattr already shows. On an error, or on a kernel without this change, STATX_ACL is left out of stx_mask and the caller reads the ACL as before. A file system that reads its ACLs through ->get_acl alone, such as ecryptfs, answers without it too, since get_inode_acl with no dentry caches no ACL there, which getfacl would then show. Only a caller that asks pays for the lookup.
Original PR: #387