> > > > 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. CC-d linux-security-module, James Morris. > > > 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. Nobody wants to send vfsmounts to the filesystem. But vfs_...() are still part of the "upper layer", not the filesystem, so I'm not convinced yet. For example: -extern int vfs_mkdir(struct inode *, struct dentry *, int); +extern int vfs_mkdir(const struct path *, struct dentry *, int); There's one caller of vfs_mkdir that can't do this: cgroup_clone(). But that can call cgroup_mkdir() instead. And having the vfsmount available within vfs_...() functions means, that the mnt_want_write() check can be moved inside, which means that callers get simpler and less likely to be buggy. Those are all advantages IMO, regardless of any security module issues. Miklos -- 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
