Re: [PATCH 04/12] fs/namei.c: lookup_open(): move audit_inode_child() up

> Op 14-06-2026 18:44 CEST schreef Jori Koolstra <[email protected]>:
> 
>  
> In the mknod(2) path of calling vfs_create() we call audit_inode_child()
> before permission checks in may_create_dentry() (but after path-based
> LSM check). Copy this behaviour to lookup_open() and move
> audit_inode_child() to may_o_create().
> 
> Signed-off-by: Jori Koolstra <[email protected]>
> ---
>  fs/namei.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/namei.c b/fs/namei.c
> index 6bf1ded26377..a4a8cdbb48e2 100644
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -4345,6 +4345,8 @@ static int may_o_create(struct mnt_idmap *idmap,
>  	if (error)
>  		return error;
>  
> +	audit_inode_child(dir->dentry->d_inode, dentry, AUDIT_TYPE_CHILD_CREATE);
> +
>  	if (!fsuidgid_has_mapping(dir->dentry->d_sb, idmap))
>  		return -EOVERFLOW;
>  
> @@ -4532,7 +4534,6 @@ static struct dentry *lookup_open(struct nameidata *nd, struct file *file,
>  			goto out_dput;
>  
>  		file->f_mode |= FMODE_CREATED;
> -		audit_inode_child(dir_inode, dentry, AUDIT_TYPE_CHILD_CREATE);
>  		if (!dir_inode->i_op->create) {
>  			error = -EACCES;
>  			goto out_dput;
> -- 
> 2.54.0

CC, [email protected]

Went too quick with this one... audit_inode_child() probably shouldn't be called
if we are in the lookup case. So there isn't really a way to do this exactly
symmetrical to the vfs_create()/vfs_mkdir() paths.

But certainly the current implementation is also wrong. In the atomic_open case
audit_inode_child() is called only once (in the final fsnotify call in
open_last_lookups()), but in the regular ->create case audit_inode_child() is
called twice.

What behavior is actually wanted here?