On Tue, Sep 24, 2024 at 3:01 AM Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > On Mon, Sep 23, 2024 at 08:11:51PM -0400, Paul Moore wrote: > > > Umm... IIRC, sgrubb had been involved in the spec-related horrors, but > > > that was a long time ago... > > > > Yep, he was. Last I spoke to Steve a year or so ago, audit was no > > longer part of his job description; Steve still maintains his > > userspace audit tools, but that is a nights/weekends job as far as I > > understand. > > > > The last time I was involved in any audit/CC spec related work was > > well over a decade ago now, and all of those CC protection profiles > > have long since expired and been replaced. > > Interesting... I guess eparis would be the next victim^Wpossible source > of information. Eric was the one who dumped the audit subsystem in my lap ~10 years ago so he could run off and play with containers. Fortunately for Eric I was much more trusting back then and didn't read all the fine print before agreeing to look after audit. > > > * looking at the users of that stuff, I would probably prefer to > > > separate getname*() from insertion into audit context. It's not that > > > tricky - __set_nameidata() catches *everything* that uses nd->name (i.e. > > > all that audit_inode() calls in fs/namei.c use). > > > > That should be a pretty significant simplification, that sounds good to me. > > > > > ... What remains is > > > do_symlinkat() for symlink body > > > fs_index() on the argument (if we want to bother - it's a part > > > of weird Missed'em'V sysfs(2) syscall; I sincerely doubt that there's > > > anybody who'd use it) > > > > We probably should bother, folks that really care about audit don't > > like blind spots. Perhaps make it a separate patch if it isn't too > > ugly to split it out. > > Heh... I suggest you to look at the manpage of that thing. Ooof. That's something isn't it? Yeah, that's ugly, and since it doesn't really return any user or sensitive system information I think it's safe to skip - my mistake. > > > That's all it takes. With that done, we can kill ->aname; > > > just look in the ->names_list for the first entry with given ->name - > > > as in, given struct filename * value, no need to look inside. > > > > Seems reasonable to me. I can't imagine these special cases being any > > worse than what we have now in fs/namei.c, and if nothing else having > > a single catch point for the bulk of the VFS lookups makes it worth it > > as far as I'm concerned. > > Huh? Right now we allocate audit_names at getname_flags()/getname_kernel() > time; grep for audit_getname() - that's as centralized as it gets. > What I want to do is somewhat _de_centralize it; that way they would not > go anywhere other than audit_context of the thread actually doing the > work. > > There is a lot of calls of audit_inode(), but I'm not planning to touch > any of those. Sorry. I'm a bit foggy from traveling, and trying to play catch-up back at home. I'm sure it will make more sense once I see the patches. -- paul-moore.com
