From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-f181.google.com ([209.85.220.181]:35287 "EHLO mail-qk0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750937AbcCIMQL (ORCPT ); Wed, 9 Mar 2016 07:16:11 -0500 Received: by mail-qk0-f181.google.com with SMTP id o6so18994282qkc.2 for ; Wed, 09 Mar 2016 04:16:11 -0800 (PST) Subject: Re: btrfs and containers To: Chris Murphy , bo.li.liu@oracle.com References: <20160308195857.GB26981@localhost.localdomain> Cc: Tobias Hunger , Btrfs BTRFS From: "Austin S. Hemmelgarn" Message-ID: <56E013E8.9080401@gmail.com> Date: Wed, 9 Mar 2016 07:15:36 -0500 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Sender: linux-btrfs-owner@vger.kernel.org List-ID: On 2016-03-08 16:28, Chris Murphy wrote: > On Tue, Mar 8, 2016 at 12:58 PM, Liu Bo wrote: >> On Mon, Mar 07, 2016 at 04:45:09PM -0700, Chris Murphy wrote: >>> On Mon, Mar 7, 2016 at 3:55 PM, Tobias Hunger wrote: >>>> Hi, >>>> >>>> I have been running systemd-nspawn containers on top of a btrfs >>>> filesystem for a while now. >>>> >>>> This works great: Snapshots are a huge help to manage containers! >>>> >>>> But today I ran btrfs subvol list . *inside* a container. To my >>>> surprise I got a list of *all* subvolumes on that drive. That is >>>> basically a complete list of containers running on the machine. I do >>>> not want to have that kind of information exposed to my containers. >>>> >>>> Is there a way to stop btrfs from listing subvolumes "above" the >>>> current location? So that "btrfs subvol list /" in a container will >>>> only show subvolumes that are set up in the container? >> >> That's a good question. >> >> Looks like that "btrfs subvolume list -o" match the needs here. >> >>> >>> I'm not sure whether this is something that goes in Btrfs proper, >>> since this is presumably a privileged container? The same thing >>> happens with Docker containers. One way to do this is if it's not >>> privileged, as non-root can't list subvolumes. I think some work is >>> needed to make it possible for users to list subvolumes they own. >>> Right now a user can create a subvolume but then now list or get >>> information on it. By default they can't delete it either unless a >>> special mount option is used. So I think there's work that's needed >>> one way or another, and maybe in more than one part. >> >> Unfortunately, btrfs subvolume list 's various usage is built on top of TREE_SEARCH ioctl >> which requires CAP_SYS_ADMIN. >> >> So what we need here might be to teach 'btrfs sub list' to recognize >> container's CAP_SYS_XXX (if this is possible). > > > Yes, it's a bit peculiar I can create subvolumes and snapshot them, > but can't 'btrfs sub list/show' > > It's an open question why the user needs a subvolume, but I'm not > thinking of a human user necessarily but rather some service, maybe > it's httpd. Or maybe with the xdg-app stuff the Gnome folks are > working on it makes sense to encapsulate applications and their > updates in their own subvolume. *shrug* I'm open to the idea that the > use case needs to be more compelling and detailed in order to get the > implementation right. > It's probably worth tossing out there that I use them on a regular basis as a normal user (not root or some service) for: 1. Local copies of VCS repositories. 2. Build directories. 3. Staging areas for a variety of things. 4. Specifically isolating certain parts of my home directory from backups. 1-3 are mostly because of the fact that deleting a subvolume is insanely fast compared to recursive deletion of a directory, although 4 is somewhat significant for those as well. In general I can see them being useful for any number of things from a service perspective, although I feel that snapshots are likely more useful there (the ability to atomically save the state of a set of files is extremely useful for a lot of things).