* 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;
as well as URLs for NNTP newsgroup(s).