On Mon, Jun 15, 2026 at 5:43 PM Jori Koolstra <[email protected]> wrote: > > 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(-)
... > 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? 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
