* Setting FS_USERNS_MOUNT in btrfs_fs_type.fs_flags @ 2014-09-17 3:05 Shea Levy 2014-09-17 3:54 ` Al Viro 0 siblings, 1 reply; 4+ messages in thread From: Shea Levy @ 2014-09-17 3:05 UTC (permalink / raw) To: linux-btrfs; +Cc: linux-kernel 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Setting FS_USERNS_MOUNT in btrfs_fs_type.fs_flags 2014-09-17 3:05 Setting FS_USERNS_MOUNT in btrfs_fs_type.fs_flags Shea Levy @ 2014-09-17 3:54 ` Al Viro 2014-09-17 16:12 ` Zach Brown 0 siblings, 1 reply; 4+ messages in thread From: Al Viro @ 2014-09-17 3:54 UTC (permalink / raw) To: Shea Levy; +Cc: linux-btrfs, linux-kernel 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. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Setting FS_USERNS_MOUNT in btrfs_fs_type.fs_flags 2014-09-17 3:54 ` Al Viro @ 2014-09-17 16:12 ` Zach Brown 2014-09-17 20:31 ` Shea Levy 0 siblings, 1 reply; 4+ messages in thread From: Zach Brown @ 2014-09-17 16:12 UTC (permalink / raw) To: Al Viro; +Cc: Shea Levy, linux-btrfs, linux-kernel 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) ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Setting FS_USERNS_MOUNT in btrfs_fs_type.fs_flags 2014-09-17 16:12 ` Zach Brown @ 2014-09-17 20:31 ` Shea Levy 0 siblings, 0 replies; 4+ messages in thread From: Shea Levy @ 2014-09-17 20:31 UTC (permalink / raw) To: Zach Brown; +Cc: Al Viro, linux-btrfs, linux-kernel 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2014-09-17 20:31 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-09-17 3:05 Setting FS_USERNS_MOUNT in btrfs_fs_type.fs_flags Shea Levy 2014-09-17 3:54 ` Al Viro 2014-09-17 16:12 ` Zach Brown 2014-09-17 20:31 ` Shea Levy
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox