All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@zeniv.linux.org.uk>
To: linux-fsdevel@vger.kernel.org
Cc: audit@vger.kernel.org, io-uring@vger.kernel.org
Subject: Re: [RFC] struct filename, io_uring and audit troubles
Date: Sun, 22 Sep 2024 05:10:06 +0100	[thread overview]
Message-ID: <20240922041006.GC3413968@ZenIV> (raw)
In-Reply-To: <20240922004901.GA3413968@ZenIV>

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 ;-/

  reply	other threads:[~2024-09-22  4:10 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-22  0:49 [RFC] struct filename, io_uring and audit troubles Al Viro
2024-09-22  4:10 ` Al Viro [this message]
2024-09-22 15:09   ` Al Viro
2024-09-23  1:50 ` Al Viro
2024-09-23  6:30   ` Jens Axboe
2024-09-23 12:54     ` Paul Moore
2024-09-23 14:48       ` Al Viro
2024-09-23 16:14         ` Paul Moore
2024-09-23 18:17           ` Al Viro
2024-09-23 23:49             ` Paul Moore
2024-09-23 20:36           ` Al Viro
2024-09-24  0:11             ` Paul Moore
2024-09-24  7:01               ` Al Viro
2024-09-24 23:17                 ` Paul Moore
2024-09-25 20:44               ` Al Viro
2024-09-25 20:58                 ` Paul Moore
2024-09-24 21:40             ` Al Viro
2024-09-25  6:01               ` Jens Axboe
2024-09-25 17:39                 ` Al Viro
2024-09-25 17:58                   ` Jens Axboe
2024-09-26  3:56                 ` Al Viro
2024-09-23 15:07     ` Al Viro
2024-09-24 11:15       ` Jens Axboe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240922041006.GC3413968@ZenIV \
    --to=viro@zeniv.linux.org.uk \
    --cc=audit@vger.kernel.org \
    --cc=io-uring@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.