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>". 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. -- paul-moore.com
