> 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. Or we can introduce another set of exported functions (path_mkdir(), ...), and leave vfs_...() alone. And then the only question is if LSM's can live with ordering change. 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
