[RFC] vfs: security: Parse dev_name before calling security_sb_mount

[Al Viro]

On Tue, Jul 08, 2025 at 04:05:04PM -0700, Song Liu wrote:
> security_sb_mount handles multiple types of mounts: new mount, bind
> mount, etc. When parameter dev_name is a path, it need to be parsed
> with kern_path.
> 
> Move the parsing of dev_name to path_mount, and pass the result to
> security_sb_mount, so that:
> 1. The LSMs do not need to call kern_path again;
> 2. For BPF LSM, we can use struct path dev_path, which is much easier to
>    use than a string.
> 3. We can now remove do_move_mount_old.
> 
> Also, move may_mount check to before security_sb_mount and potential
> kern_path, so that requests without proper capability will be rejected
> sooner.
> 
> Signed-off-by: Song Liu <song at kernel.org>
> 
> ---
> The primary motivation of this change is to monitor bind mount and move
> mount in BPF LSM. There are a few options for this to work:
> 1. Introduce bpf_kern_path kfunc.
> 2. Add new hook(s), such as [1].
> 3. Something like this patch.
> 
> At this moment, I think this patch is the best solution.
> 
> New mount for filesystems with FS_REQUIRES_DEV also need kern_path for
> dev_name. apparmor and tomoyo still call kern_path in such cases.
> However, it is a bit tricky to move this kern_path call to path_mount,
> so new mount path is not changed in this version.

security_sb_mount() is and had always been a mind-boggling trash of an API.

It makes no sense in terms of operations being requested.  And any questions
regarding its semantics had been consistently met with blanket "piss off,
LSM gets to do whatever it wants to do, you are not to question the sanity
and you are not to request any kind of rules - give us the fucking syscall
arguments and let us at it".

Come up with a saner API.  We are done accomodating that idiocy.  The only
changes you get to make in fs/namespace.c are "here's our better-defined
hooks, please call <this hook> when you do <that>".

NAKed-by: Al Viro <viro at zeniv.linux.org.uk>