On Thu, Mar 10, 2016 at 10:04 AM, Austin S. Hemmelgarn <[email protected]> wrote:
> > The part that makes this tricky is that the list ioctl can be considered a > potential information leak (as evidenced by the issue that started this > thread), so IMHO what really needs to happen is for the mount option to be > 'user_subvolume_ops', and control all three operations (or better yet, do > something with ACL's in the btrfs xattr namespace to control it on a > per-subvolume basis). This may also interact with the selinux + Btrfs + Docker issue. The problem is the desire to use -o context to mount a subvolume with a specific context for use with a specific container. But right now the kernel won't allow different contexts for a given fs superblock. The work around until recently is disabling Docker selinux support. The recent work around in Docker 1.10 is it snapshots the docker image, an uses chcon -R to to relabel it. It's actually pretty fast, but still suboptimal. Being able to bind mount a subvolume with -o context is faster than relabeling, with many containers it's a lot of relabeling without it. It's a tricky problem. If you're the owner of a filesystem tree, but something definitely not owned at all by you is buried in that tree somewhere, to do a subvolume delete don't you have to now traverse the entire thing to find out? Or does the owning user have sufficient implied permission by owning the subvolume, that no matter what's in it, is simply gone unless it's another subvolume? -- Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
