Seth Forshee <seth.forshee@xxxxxxxxxxxxx> writes: > On Mon, Jan 04, 2016 at 12:03:39PM -0600, Seth Forshee wrote: >> These patches implement support for mounting filesystems in user >> namespaces using fuse. They are based on the patches in the for-testing >> branch of >> git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git, >> but I've rebased them onto 4.4-rc3. I've pushed all of this to: >> >> git://git.kernel.org/pub/scm/linux/kernel/git/sforshee/linux.git fuse-userns >> >> The patches are organized into three high-level groups. >> >> Patches 1-6 are related to security, adding restrictions for >> unprivileged mounts and updating the LSMs as needed. Patches 1-2 >> (checking inode permissions for block device mounts) may not be strictly >> necessary for fuseblk mounts since fuse doesn't do any IO on the block >> device in the kernel, but it still seems like a good idea to fail the >> mount if the user doesn't have the required permissions for the inode >> (though this is a bit misleading with fuse since the mounts are done via >> a suid-root helper). >> >> Patches 7-14 update most of the vfs to translate ids correctly and deal >> with inodes which may have invalid user/group ids. I've omitted patches >> for anything not used by fuse - quota, fs freezing, some helper >> functions, etc. - but if these are wanted for the sake of completeness I >> can include them. >> >> Patches 15-18 update fuse to deal with mounts from non-init pid and user >> namespaces and enable mounting from user namespaces. >> >> Changes since v1: >> - Drop patch for FIBMAP. >> - Use current_in_userns in fuse_allow_current_process. >> - Remove checks for uid/gid validity in fuse. Intead, ids from the >> backing store which do not map into s_user_ns will result in invalid >> ids in the vfs inode. Checks in the vfs will prevent unmappable ids >> from being passed in from above. >> - Update a couple of commit messages to provide more detail about >> changes. > > Now that the merge window is over, I'm wondering whether it might be > possible to get some feedback on these patches this cycle? Definitely. Apologies for not giving you much feedback earlier. I had been hoping this was the kind of thing I could just double check to be certain you weren't doing anything silly and just apply. After my last round of looking at this I realized that for me to be comfortable with these patches I will have to give them very close scrutiny, and check every detail. Unfortunatly last cycle I had failed to budget enough time to give these patches the close scrutiny they need. >From a high level I am still very much in favor of this approach and at least getting as far as safe unprivileged fuse mounts. I have one or two little things to look at and then I hope to be going through your patches one by one in detail. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-bcache" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
