I'm not opposed to seeing better support for struct filename, I think in a lot of cases that would make things easier for audit (especially where I would like to take audit ... eventually). Assuming your ideas for struct filename don't significantly break audit you can consider me supportive so long as we still have a way to take a struct filename reference inside the audit_context; we need to keep that ref until syscall/io_uring-op exit time as we can't be certain if we need to log the PATH until we know the success/fail status of the operation (among other things). > And having everything that passed through getname()/getname_kernel() > shoved into ->names_list leads to very odd behaviour, especially with > audit_names conversions in audit_inode()/audit_inode_child(). > > Look at the handling of AUDIT_DEV{MAJOR,MINOR} or AUDIT_OBJ_{UID,GID} > or AUDIT_COMPARE_..._TO_OBJ; should they really apply to audit_names > resulting from copying the symlink body into the kernel? And if they > should be applied to audit_names instance that had never been associated > with any inode, should that depend upon the string in those being > equal to another argument of the same syscall? > > I'm going through the kernel/auditsc.c right now, but it's more of > a "document what it does" - I don't have the specs and I certainly > don't remember such details. My approach to audit is "do what makes sense for a normal person", if somebody needs silly behavior to satisfy some security cert then they can get involved in upstream development and send me patches that don't suck. -- paul-moore.com