# Re: \[PATCH RESEND v2 00/19\] Support fuse mounts in user namespaces - List: linux-raid - 2 messages, 2 authors - Page: https://ratatoskr.run/linux-raid/2016/01/103176/t ## Re: \[PATCH RESEND v2 00/19\] Support fuse mounts in user namespaces - From: Eric W. Biederman \ - Date: 2016-01-25 20:01:22 - Message: https://ratatoskr.run/linux-raid/2016/01/103176.md ```text Seth Forshee [ref] 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 ``` ## Re: \[PATCH RESEND v2 00/19\] Support fuse mounts in user namespaces - From: Seth Forshee \ - Date: 2016-01-25 20:37:55 - Message: https://ratatoskr.run/linux-raid/2016/01/103175.md ```text On Mon, Jan 25, 2016 at 02:01:22PM -0600, Eric W. Biederman wrote: > Seth Forshee [ref] 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. Great. Thanks Eric. ```