Hi Al and Paul, Thanks for your comments! > On Jul 9, 2025, at 8:19 AM, Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > > On Wed, Jul 9, 2025 at 6:24 AM Al Viro <viro@xxxxxxxxxxxxxxxxxx> 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
