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

[Song Liu]

Hi Al and Paul, 

Thanks for your comments!

> On Jul 9, 2025, at 8:19 AM, Paul Moore <paul at paul-moore.com> wrote:
> 
> On Wed, Jul 9, 2025 at 6:24 AM Al Viro <viro at zeniv.linux.org.uk> wrote:
>> 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.
> 
> ...
> 
>> 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".
> 
> I'm not going to comment on past remarks made by other devs, but I do
> want to make it clear that I am interested in making sure we have LSM
> hooks which satisfy both the needs of the existing in-tree LSMs while
> also presenting a sane API to the kernel subsystems in which they are
> placed.  I'm happy to revisit any of our existing LSM hooks to
> restructure them to better fit these goals; simply send some patches
> and let's discuss them.
> 
>> 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>".

Right now, we have security_sb_mount and security_move_mount, for 
syscall “mount” and “move_mount” respectively. This is confusing 
because we can also do move mount with syscall “mount”. How about 
we create 5 different security hooks:

security_bind_mount
security_new_mount
security_reconfigure_mount
security_remount
security_change_type_mount

and remove security_sb_mount. After this, we will have 6 hooks for
each type of mount (the 5 above plus security_move_mount). 

> 
> I don't have the cycles to revisit the security_sb_mount() hook
> myself, but perhaps Song Liu does with some suggestions/guidance from
> you or Christian on what an improved LSM hook would look like from a
> VFS perspective.

Thanks,
Song