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

[Paul Moore]

On Mon, Jun 15, 2026 at 5:43 PM Jori Koolstra <jkoolstra@xxxxxxxxx> wrote:
> > Op 14-06-2026 18:44 CEST schreef Jori Koolstra <jkoolstra@xxxxxxxxx>:
> >
> > 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 <jkoolstra@xxxxxxxxx>
> > ---
> >  fs/namei.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)

...

> CC, audit@xxxxxxxxxxxxxxx
>
> 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?

I haven't looked at the VFS open/create code in a while, and I'm kinda
swamped with other things at the moment so a few pointers would go a
long way towards helping get the right context for your question.

We shouldn't *need* multiple calls into audit_inode_child() for a
given filesystem object as long as all of the information audit needs
can be captured in the single call site.

-- 
paul-moore.com