Re: Setting FS_USERNS_MOUNT in btrfs_fs_type.fs_flags
On Wed, Sep 17, 2014 at 04:54:48AM +0100, Al Viro wrote: On Tue, Sep 16, 2014 at 11:05:00PM -0400, Shea Levy wrote: Hi all, What work would be required to mark btrfs_fs_type with FS_USERNS_MOUNT so that btrfs images can be mounted by unprivileged users within a user namespace (along with something like [1])? I'd like to be able to create disk images without having to start a VM (and --rootdir isn't flexible enough because I want to make subvolumes). Er... Which is to say, you have an audit of btrfs code making sure that it can cope with arbitrary image hand-crafted by potential attacker? It definitely can't cope. The easiest places to find bugs are the hundreds of BUG_ON() sites, many can be triggered by on-disk structures. The sheer volume of those makes me trust that you could find much worse if you did a thorough audit. - z (fun related fact: distros automount btrfs images) -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Setting FS_USERNS_MOUNT in btrfs_fs_type.fs_flags
On Wed, Sep 17, 2014 at 09:12:14AM -0700, Zach Brown wrote: On Wed, Sep 17, 2014 at 04:54:48AM +0100, Al Viro wrote: On Tue, Sep 16, 2014 at 11:05:00PM -0400, Shea Levy wrote: Hi all, What work would be required to mark btrfs_fs_type with FS_USERNS_MOUNT so that btrfs images can be mounted by unprivileged users within a user namespace (along with something like [1])? I'd like to be able to create disk images without having to start a VM (and --rootdir isn't flexible enough because I want to make subvolumes). Er... Which is to say, you have an audit of btrfs code making sure that it can cope with arbitrary image hand-crafted by potential attacker? It definitely can't cope. The easiest places to find bugs are the hundreds of BUG_ON() sites, many can be triggered by on-disk structures. The sheer volume of those makes me trust that you could find much worse if you did a thorough audit. - z (fun related fact: distros automount btrfs images) OK, so it seems like the answer to my question is a helluva lot. Guess I won't count on seeing it any time soon :) Thanks, Shea -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Setting FS_USERNS_MOUNT in btrfs_fs_type.fs_flags
Hi all, What work would be required to mark btrfs_fs_type with FS_USERNS_MOUNT so that btrfs images can be mounted by unprivileged users within a user namespace (along with something like [1])? I'd like to be able to create disk images without having to start a VM (and --rootdir isn't flexible enough because I want to make subvolumes). Cheers, Shea Levy P.S. I am not subscribed to either list, please CC me in replies [1] https://lkml.org/lkml/2014/5/27/690 -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Setting FS_USERNS_MOUNT in btrfs_fs_type.fs_flags
On Tue, Sep 16, 2014 at 11:05:00PM -0400, Shea Levy wrote: Hi all, What work would be required to mark btrfs_fs_type with FS_USERNS_MOUNT so that btrfs images can be mounted by unprivileged users within a user namespace (along with something like [1])? I'd like to be able to create disk images without having to start a VM (and --rootdir isn't flexible enough because I want to make subvolumes). Er... Which is to say, you have an audit of btrfs code making sure that it can cope with arbitrary image hand-crafted by potential attacker? Because without that FS_USERNS_MOUNT could open one hell of security hole; things like user being able to execute an arbitrary code in kernel mode, etc. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
