kernel/linux.git/security/inode.c, branch v6.19.11

Merge tag 'pull-persistency' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs

2025-12-05T22:36:21+00:00

Pull persistent dentry infrastructure and conversion from Al Viro: "Some filesystems use a kinda-sorta controlled dentry refcount leak to pin dentries of created objects in dcache (and undo it when removing those). A reference is grabbed and not released, but it's not actually _stored_ anywhere. That works, but it's hard to follow and verify; among other things, we have no way to tell _which_ of the increments is intended to be an unpaired one. Worse, on removal we need to decide whether the reference had already been dropped, which can be non-trivial if that removal is on umount and we need to figure out if this dentry is pinned due to e.g. unlink() not done. Usually that is handled by using kill_litter_super() as ->kill_sb(), but there are open-coded special cases of the same (consider e.g. /proc/self). Things get simpler if we introduce a new dentry flag (DCACHE_PERSISTENT) marking those "leaked" dentries. Having it set claims responsibility for +1 in refcount. The end result this series is aiming for: - get these unbalanced dget() and dput() replaced with new primitives that would, in addition to adjusting refcount, set and clear persistency flag. - instead of having kill_litter_super() mess with removing the remaining "leaked" references (e.g. for all tmpfs files that hadn't been removed prior to umount), have the regular shrink_dcache_for_umount() strip DCACHE_PERSISTENT of all dentries, dropping the corresponding reference if it had been set. After that kill_litter_super() becomes an equivalent of kill_anon_super(). Doing that in a single step is not feasible - it would affect too many places in too many filesystems. It has to be split into a series. This work has really started early in 2024; quite a few preliminary pieces have already gone into mainline. This chunk is finally getting to the meat of that stuff - infrastructure and most of the conversions to it. Some pieces are still sitting in the local branches, but the bulk of that stuff is here" * tag 'pull-persistency' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: (54 commits) d_make_discardable(): warn if given a non-persistent dentry kill securityfs_recursive_remove() convert securityfs get rid of kill_litter_super() convert rust_binderfs convert nfsctl convert rpc_pipefs convert hypfs hypfs: swich hypfs_create_u64() to returning int hypfs: switch hypfs_create_str() to returning int hypfs: don't pin dentries twice convert gadgetfs gadgetfs: switch to simple_remove_by_name() convert functionfs functionfs: switch to simple_remove_by_name() functionfs: fix the open/removal races functionfs: need to cancel ->reset_work in ->kill_sb() functionfs: don't bother with ffs->ref in ffs_data_{opened,closed}() functionfs: don't abuse ffs_data_closed() on fs shutdown convert selinuxfs ...

convert securityfs

2025-11-18T04:59:27+00:00

securityfs uses simple_recursive_removal(), but does not bother to mark dentries persistent. This is the only place where it still happens; get rid of that irregularity. * use simple_{start,done}_creating() and d_make_persitent(); kill_litter_super() use was already gone, since we empty the filesystem instance before it gets shut down. Acked-by: Paul Moore Signed-off-by: Al Viro

configfs, securityfs: kill_litter_super() not needed

2025-11-16T06:35:02+00:00

These are guaranteed to be empty by the time they are shut down; both are single-instance and there is an internal mount maintained for as long as there is any contents. Both have that internal mount pinned by every object in root. In other words, kill_litter_super() boils down to kill_anon_super() for those. Reviewed-by: Joel Becker Acked-by: Paul Moore (LSM) Acked-by: Andreas Hindborg (configfs) Signed-off-by: Al Viro

lsm: consolidate all of the LSM framework initcalls

2025-10-22T23:24:28+00:00

The LSM framework itself registers a small number of initcalls, this patch converts these initcalls into the new initcall mechanism. Reviewed-by: Casey Schaufler Reviewed-by: John Johansen Signed-off-by: Paul Moore

lsm: get rid of the lsm_names list and do some cleanup

2025-10-22T23:24:19+00:00

The LSM currently has a lot of code to maintain a list of the currently active LSMs in a human readable string, with the only user being the "/sys/kernel/security/lsm" code. Let's drop all of that code and generate the string on first use and then cache it for subsequent use. Signed-off-by: Paul Moore

make securityfs_remove() remove the entire subtree

2025-06-11T22:19:46+00:00

... and fix the mount leak when anything's mounted there. securityfs_recursive_remove becomes an alias for securityfs_remove - we'll probably need to remove it in a cycle or two. Signed-off-by: Al Viro

securityfs: pin filesystem only for objects directly in root

2025-06-11T22:00:00+00:00

Nothing on securityfs ever changes parents, so we don't need to pin the internal mount if it's already pinned for parent. Signed-off-by: Al Viro

securityfs: don't pin dentries twice, once is enough...

2025-06-11T19:07:57+00:00

incidentally, securityfs_recursive_remove() is broken without that - it leaks dentries, since simple_recursive_removal() does not expect anything of that sort. It could be worked around by dput() in remove_one() callback, but it's easier to just drop that double-get stuff. Signed-off-by: Al Viro

VFS: rename lookup_one_len family to lookup_noperm and remove permission check

2025-04-08T09:24:36+00:00

The lookup_one_len family of functions is (now) only used internally by a filesystem on itself either - in a context where permission checking is irrelevant such as by a virtual filesystem populating itself, or xfs accessing its ORPHANAGE or dquota accessing the quota file; or - in a context where a permission check (MAY_EXEC on the parent) has just been performed such as a network filesystem finding in "silly-rename" file in the same directory. This is also the context after the _parentat() functions where currently lookup_one_qstr_excl() is used. So the permission check is pointless. The name "one_len" is unhelpful in understanding the purpose of these functions and should be changed. Most of the callers pass the len as "strlen()" so using a qstr and QSTR() can simplify the code. This patch renames these functions (include lookup_positive_unlocked() which is part of the family despite the name) to have a name based on "lookup_noperm". They are changed to receive a 'struct qstr' instead of separate name and len. In a few cases the use of QSTR() results in a new call to strlen(). try_lookup_noperm() takes a pointer to a qstr instead of the whole qstr. This is consistent with d_hash_and_lookup() (which is nearly identical) and useful for lookup_noperm_unlocked(). The new lookup_noperm_common() doesn't take a qstr yet. That will be tidied up in a subsequent patch. Signed-off-by: NeilBrown Link: https://lore.kernel.org/r/20250319031545.2999807-5-neil@brown.name Signed-off-by: Christian Brauner

lsm: Use IS_ERR_OR_NULL() helper function

2024-08-29T15:12:13+00:00

Use the IS_ERR_OR_NULL() helper instead of open-coding a NULL and an error pointer checks to simplify the code and improve readability. Signed-off-by: Hongbo Li Signed-off-by: Paul Moore