Re: [RFC][PATCH 10/13] get rid of audit_reusename()

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

On Mon, Nov 10, 2025 at 12:52:57PM -0800, Linus Torvalds wrote:
> On Mon, 10 Nov 2025 at 11:58, Al Viro <viro@zeniv.linux.org.uk> wrote:
> >
> > If we go that way, do you see any problems with treating
> > osf_{ufs,cdfs}_mount() in the same manner?  Yes, these are pathnames,
> 
> Hmm. In those cases, the ENAMETOOLONG thing actually does make sense -
> exactly because they are pathnames.
> 
> So I think that in those two places using getname() is fairly natural
> and gets us the natural error handling too. No?

Seeing that we don't do that for native mount(2)...  Hell knows -
the thing is, import is done early in syscall, before we know what
does that particular filesystem type expect.  It's not always a pathname
of any sort.

Note that empty string for the first argument of mount(2) is perfectly
fine - for some values of the 5th (flags) and 3rd (type) ones.
So plain getname() is not an option and we do, unfortunately, need the
sucker imported before we start parsing the flags, etc.

I'd love to take security_sb_mount() - it's an utter shitshow of API,
inherently racy, etc., but currently it takes a kernelspace string for
the first argument (dev_name) and is called before we'd even started
to look at flags (so the instances have to essentially duplicate flags
parsing, among other things).

But that's a lot of massage and it will require the LSM crowd acceptance ;-/
If earlier attempts are anything to go by, there will be a lot of
resistance.

BTW, take a look at apparmor_sb_mount() and aa_bind_mount().  Compare
the calls of kern_path() in aa_bind_mount() and in do_loopback() and
note that the damn thing relies upon both pathwalks resolving to the
same location...