On Fri, Mar 21, 2008 at 05:24:11PM +0100, Miklos Szeredi wrote: > > > I know there are a few cases, where filesystems call vfs_foo() > > > internally, where the vfsmount isn't available, but I think the proper > > > solution is just to fix those places, and not recurse back into the > > > VFS (which is AFAICS in all those cases totally unnecessary anyway). > > > This would make everybody happy, no? > > > > Apparmor can go play with itself. The proper fix is to lift the LSM nonsense > > into callers and leave vfs_...() alone; > > Maybe. I know precious little about this security thing, so I won't > argue about it's merits or faults. But: > > a) I have a hunch that the security guys wouldn't like to see the > order between permission() and security_foo() changed. It's their problem. Adjusting LSM methods, if needed, is up to LSM maintainers, whenever moving the hooks or code around those become convenient for kernel proper. According to Linus, IIRC. Especially since in this case they want to change prototypes anyway, so the churn is not an issue and having the hook called earlier is very unlikely to cause any problems. > b) I fail to see how moving functionality to callers would improve > things > > > vfsmounts should *not* be passed there at all, with the exception of > > vfs_follow_link() which gets the full nameidata. > > Why? Because filesystem shouldn't _care_ where it is mounted. Anything vfsmount-dependent belongs to upper layers. The same goes for passing nameidata to fs methods, BTW - again, ->follow_link() is an obvious legitimate exception. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
