On 2016-03-08 16:28, Chris Murphy wrote:
On Tue, Mar 8, 2016 at 12:58 PM, Liu Bo <bo.li....@oracle.com> 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 <tobias.hun...@gmail.com> 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).
--
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
