Re: [RFC] struct filename, io_uring and audit troubles

[Al Viro <viro@zeniv.linux.org.uk>]

On Sun, Sep 22, 2024 at 05:10:06AM +0100, Al Viro wrote:
> On Sun, Sep 22, 2024 at 01:49:01AM +0100, Al Viro wrote:
> 
> > * don't bother with audit_name creation and linkage in getname(); do that
> > when we start using the sucker.  Doing that from __set_nameidata() will
> > catch the majority of the stuff that ever gets audit_inode* called for it
> > (the only exceptions are mq_open(2) and mq_unlink(2)).  Unfortunately,
> > each audit_name instance gets spewed into logs, so we would need to
> > bring the rest of that shite in, including the things like symlink
> > bodies (note that for io_uring-originating symlink we'd need that done
> > in do_symlinkat()), etc.  Unpleasant, that.
> 
> BTW, how much is exact order and number of PATH items in audit logs cast
> in stone?
> 
> For example,
>         char s[2][20] = {"/tmp/blah/x", "/tmp/blah/x"};
> 	rename(s[0], s[1]);
> 	rename(s[0], s[0]);
> 
> produces 2 items (both for /tmp/blah) on the first call, and only 1 on
> the second.  Does anything care about preserving that distinction?
> 
> And what in audit_inode{,_child}() behaviour can be changed?  I mean, does
> anything care about the loop directions when we pick the candidate
> audit_name for conversion, etc.?
> 
> It's been a long time since I've touched audit, and I have done my best
> to purge memories of the specifications ;-/

Speaking of which, is there anything in specs that would require -F obj_uid=0
to give a match on symlink("foo", "bar") done by non-root in non-root-owned
directory, but not on symlink("foo", "foo") in the same conditions?

Put it another way, could we possibly make the predicates that refer to inode
state *not* evaluate to true on audit_name instances that had never been
associated with any inodes?  Currently, symlink body has such an audit_name
instance, except when that instance had been picked by audit_inode_parent()
for conversion (or had been shared from the very beginning in case of symlink(2)
that had identical pointers passed in both arguments).

Al, carefully abstaining from any comments on the sanity of said specifications -
it's a government document, after all, so those should be obvious...