Re: Moving an entire subvol?

[Duncan <1i5t5.duncan@cox.net>]

Shriramana Sharma posted on Tue, 02 Dec 2014 08:51:40 +0530 as excerpted:

> On Mon, Dec 1, 2014 at 6:24 AM, Chris Murphy <lists@colorremedies.com>
> wrote:
>>> But isn't it just possible to move i.e. reparent a subvol so I can
>>> move these two under another subvol and have that as default?
>>
>> You can move subvolumes.
> 
> OK so I just found out that just mv test1/foo test2/ where test1,
> test2 and foo are all subvolumes is sufficient to reparent foo to test2,
> if what btr sub list shows as "top level" is indeed the parent
> subvolume.
> 
> Is that correct: what btr sub list shows as "top level" is indeed the
> parent subvolume?

[Noting that my use-case doesn't involve subvolumes so while I've played 
with them a bit my direct knowledge is limited...]

It should be correct, yes.

Subvolumes are in many ways "super-directories", so it's little surprise 
simply directory manipulation such as moves would do what you might 
expect.  They just happen to be directly mountable too, and to have 
various btrfs-specific effects such as snapshots stopping at subvolume 
boundaries, usage for btrfs send/receive, etc.

>> My suggestion is subvolumes containing binaries shouldn't be located
>> within another subvolume that ends up being mounted, that way old
>> binaries with possible vulnerabilities aren't exposed in the normal
>> search path.
> 
> I'm not sure what you mean. Are you saying that for example /usr/bin
> should be:
> 
> 1) a separate subvolume than / or /usr,
> 2) not a child subvolume of / or /usr?

What I believe he's referencing is the potential security issue if for 
example you have older snapshots of /usr (which would include /usr/bin 
and /usr/lib(64)) accessible under normal operating conditions.  These 
snapshots would contain older versions of binaries (and libraries) that 
have been security-updated on the main system, but the snapshots would of 
course contain the still vulnerable versions.  A user trying to do a root-
escalation, for instance, could then access and run one of these old and 
vulnerable versions by specifying the full path instead of just the name, 
thus getting access to a known root-escalation vuln long since patched in 
the main path but still vulnerable in the snapshot path.

If for instance the master id=5 subvolume is still the default and 
routinely mounted, it will have all snapshots appearing as directories 
somewhere beneath its mountpoint in the tree.  If those snapshots contain 
bin or lib dirs, the above security scenario is a real possibility, since 
they'll be accessible in the tree.

So making something other than the master id=5 subvolume the default, 
mounting id=5 only when doing subvolume maintenance not routinely, and 
making such bin/lib-containing snapshots direct children of id=5 instead 
of children of the / subvolume or the like, will keep the snapshots 
containing the possibly vulnerable bins/libs out of normal accessibility 
as they'll only be visible in the tree when id=5 is mounted for snapshot 
maintenance, etc.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman