* Confusion about snapshots containers
@ 2017-03-29 21:27 Tim Cuthbertson
2017-03-29 21:55 ` Hugo Mills
2017-03-31 17:40 ` Kai Krakow
0 siblings, 2 replies; 7+ messages in thread
From: Tim Cuthbertson @ 2017-03-29 21:27 UTC (permalink / raw)
To: linux-btrfs
I have recently switched from multiple partitions with multiple
btrfs's to a flat layout. I will try to keep my question concise.
I am confused as to whether a snapshots container should be a normal
directory or a mountable subvolume. I do not understand how it can be
a normal directory while being at the same level as, for example, a
rootfs subvolume. This is with the understanding that the rootfs is
NOT at the btrfs top level.
Which should it be, a normal directory or a mountable subvolume
directly under btrfs top level? If either way can work, what are the
pros and cons of each?
Thank you
Tim Cuthbertson
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Confusion about snapshots containers
2017-03-29 21:27 Confusion about snapshots containers Tim Cuthbertson
@ 2017-03-29 21:55 ` Hugo Mills
2017-03-29 23:20 ` Fwd: " Tim Cuthbertson
2017-03-31 17:40 ` Kai Krakow
1 sibling, 1 reply; 7+ messages in thread
From: Hugo Mills @ 2017-03-29 21:55 UTC (permalink / raw)
To: Tim Cuthbertson; +Cc: linux-btrfs
[-- Attachment #1: Type: text/plain, Size: 1766 bytes --]
On Wed, Mar 29, 2017 at 04:27:30PM -0500, Tim Cuthbertson wrote:
> I have recently switched from multiple partitions with multiple
> btrfs's to a flat layout. I will try to keep my question concise.
>
> I am confused as to whether a snapshots container should be a normal
> directory or a mountable subvolume. I do not understand how it can be
> a normal directory while being at the same level as, for example, a
> rootfs subvolume. This is with the understanding that the rootfs is
> NOT at the btrfs top level.
>
> Which should it be, a normal directory or a mountable subvolume
> directly under btrfs top level? If either way can work, what are the
> pros and cons of each?
The current best practice recommendation is that it should be a
normal directory, not contained within any of the subvolumes that are
being snapshotted. So (using the @-prefix convention to indicate a
subvol), you'd have something like this:
<top-level>
@root
@home
snapshots
root
@2017-03-28
@2017-03-29
home
@2017-03-28
@2017-03-29
To use this, mount the top level of the FS (-o subvolid=0) on a
known path, such as /media/btrfs/<fslabel>/, and do the subvol
management, and nothing else, under that mount.
(Optionally, you can flatten the dir hierarchy to
/snapshots/@root-2017-03-28, but I prefer the slightly deeper version
above).
The snapshots container can be either a dir or a subvol, but you
gain almost nothing from it being a subvol, and you lose the ability
to move subvols/snapshots in and out of it cheaply with mv. Hence the
recommendation to use a directory.
Hugo.
--
Hugo Mills | O tempura! O moresushi!
hugo@... carfax.org.uk |
http://carfax.org.uk/ |
PGP: E2AB1DE4 |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Fwd: Confusion about snapshots containers
2017-03-29 21:55 ` Hugo Mills
@ 2017-03-29 23:20 ` Tim Cuthbertson
2017-03-30 3:46 ` Duncan
0 siblings, 1 reply; 7+ messages in thread
From: Tim Cuthbertson @ 2017-03-29 23:20 UTC (permalink / raw)
To: linux-btrfs
---------- Forwarded message ----------
From: Hugo Mills <hugo@carfax.org.uk>
Date: Wed, Mar 29, 2017 at 4:55 PM
Subject: Re: Confusion about snapshots containers
To: Tim Cuthbertson <ratcheer@gmail.com>
Cc: "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
On Wed, Mar 29, 2017 at 04:27:30PM -0500, Tim Cuthbertson wrote:
> I have recently switched from multiple partitions with multiple
> btrfs's to a flat layout. I will try to keep my question concise.
>
> I am confused as to whether a snapshots container should be a normal
> directory or a mountable subvolume. I do not understand how it can be
> a normal directory while being at the same level as, for example, a
> rootfs subvolume. This is with the understanding that the rootfs is
> NOT at the btrfs top level.
>
> Which should it be, a normal directory or a mountable subvolume
> directly under btrfs top level? If either way can work, what are the
> pros and cons of each?
The current best practice recommendation is that it should be a
normal directory, not contained within any of the subvolumes that are
being snapshotted. So (using the @-prefix convention to indicate a
subvol), you'd have something like this:
<top-level>
@root
@home
snapshots
root
@2017-03-28
@2017-03-29
home
@2017-03-28
@2017-03-29
To use this, mount the top level of the FS (-o subvolid=0) on a
known path, such as /media/btrfs/<fslabel>/, and do the subvol
management, and nothing else, under that mount.
(Optionally, you can flatten the dir hierarchy to
/snapshots/@root-2017-03-28, but I prefer the slightly deeper version
above).
The snapshots container can be either a dir or a subvol, but you
gain almost nothing from it being a subvol, and you lose the ability
to move subvols/snapshots in and out of it cheaply with mv. Hence the
recommendation to use a directory.
Hugo.
--
Hugo Mills | O tempura! O moresushi!
hugo@... carfax.org.uk |
http://carfax.org.uk/ |
PGP: E2AB1DE4 |
Thank you Hugo. That seems to work.
So, another question...
Do I then leave the top level mounted all the time for snapshots, or
should I create them, send them to external storage, and umount until
next time?
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Fwd: Confusion about snapshots containers
2017-03-29 23:20 ` Fwd: " Tim Cuthbertson
@ 2017-03-30 3:46 ` Duncan
2017-03-30 13:07 ` Tim Cuthbertson
0 siblings, 1 reply; 7+ messages in thread
From: Duncan @ 2017-03-30 3:46 UTC (permalink / raw)
To: linux-btrfs
Tim Cuthbertson posted on Wed, 29 Mar 2017 18:20:52 -0500 as excerpted:
> So, another question...
>
> Do I then leave the top level mounted all the time for snapshots, or
> should I create them, send them to external storage, and umount until
> next time?
Keep in mind that because snapshots contain older versions of whatever
they're snapshotting, they're a potential security issue, at least if
some of those older versions are libs or binaries. Consider the fact
that you may have had security-updates since the snapshot, thus leaving
your working copies unaffected by whatever security vulns the updates
fixed. If the old versions remain around where normal users have access
to them, particularly if they're setuid or similar, they have access to
those old and now known vulns in setuid executables! (Of course users
can grab vulnerable versions elsewhere or build them themselves, but they
can't set them setuid root unless they /are/ root, so finding an existing
setuid-root executable with known vulns is finding the keys to the
kingdom.)
So keeping snapshots unmounted and out of the normally accessible
filesystem tree by default is recommended, at least if you're at all
concerned about someone untrusted getting access to a normal user account
and being able to use snapshots with known vulns of setuid executables as
root-escalation methods.
Another possibility is setting the snapshot subdir 700 perms, so non-
super-users can't normally access anything in it anyway. Of course
that's a problem if you want them to have access to snapshots of their
own stuff for recovery purposes, but it's useful if you can do it.
Good admins will do both of these at once if possible as they know and
observe the defense-in-depth mantra, knowing all too well how easy a
single layer of defense yields to fat-fingering or previously unknown
vulns.
--
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Fwd: Confusion about snapshots containers
2017-03-30 3:46 ` Duncan
@ 2017-03-30 13:07 ` Tim Cuthbertson
2017-03-31 11:34 ` Austin S. Hemmelgarn
0 siblings, 1 reply; 7+ messages in thread
From: Tim Cuthbertson @ 2017-03-30 13:07 UTC (permalink / raw)
To: Duncan, linux-btrfs
On Wed, Mar 29, 2017 at 10:46 PM, Duncan <1i5t5.duncan@cox.net> wrote:
> Tim Cuthbertson posted on Wed, 29 Mar 2017 18:20:52 -0500 as excerpted:
>
>> So, another question...
>>
>> Do I then leave the top level mounted all the time for snapshots, or
>> should I create them, send them to external storage, and umount until
>> next time?
>
> Keep in mind that because snapshots contain older versions of whatever
> they're snapshotting, they're a potential security issue, at least if
> some of those older versions are libs or binaries. Consider the fact
> that you may have had security-updates since the snapshot, thus leaving
> your working copies unaffected by whatever security vulns the updates
> fixed. If the old versions remain around where normal users have access
> to them, particularly if they're setuid or similar, they have access to
> those old and now known vulns in setuid executables! (Of course users
> can grab vulnerable versions elsewhere or build them themselves, but they
> can't set them setuid root unless they /are/ root, so finding an existing
> setuid-root executable with known vulns is finding the keys to the
> kingdom.)
>
> So keeping snapshots unmounted and out of the normally accessible
> filesystem tree by default is recommended, at least if you're at all
> concerned about someone untrusted getting access to a normal user account
> and being able to use snapshots with known vulns of setuid executables as
> root-escalation methods.
>
> Another possibility is setting the snapshot subdir 700 perms, so non-
> super-users can't normally access anything in it anyway. Of course
> that's a problem if you want them to have access to snapshots of their
> own stuff for recovery purposes, but it's useful if you can do it.
>
> Good admins will do both of these at once if possible as they know and
> observe the defense-in-depth mantra, knowing all too well how easy a
> single layer of defense yields to fat-fingering or previously unknown
> vulns.
>
> --
> 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
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Thank you, Duncan. I will try to take all that into consideration.
These are really just fairly simple personal home systems, but
security is still important.
Tim Cuthbertson
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Fwd: Confusion about snapshots containers
2017-03-30 13:07 ` Tim Cuthbertson
@ 2017-03-31 11:34 ` Austin S. Hemmelgarn
0 siblings, 0 replies; 7+ messages in thread
From: Austin S. Hemmelgarn @ 2017-03-31 11:34 UTC (permalink / raw)
To: Tim Cuthbertson, linux-btrfs
On 2017-03-30 09:07, Tim Cuthbertson wrote:
> On Wed, Mar 29, 2017 at 10:46 PM, Duncan <1i5t5.duncan@cox.net> wrote:
>> Tim Cuthbertson posted on Wed, 29 Mar 2017 18:20:52 -0500 as excerpted:
>>
>>> So, another question...
>>>
>>> Do I then leave the top level mounted all the time for snapshots, or
>>> should I create them, send them to external storage, and umount until
>>> next time?
>>
>> Keep in mind that because snapshots contain older versions of whatever
>> they're snapshotting, they're a potential security issue, at least if
>> some of those older versions are libs or binaries. Consider the fact
>> that you may have had security-updates since the snapshot, thus leaving
>> your working copies unaffected by whatever security vulns the updates
>> fixed. If the old versions remain around where normal users have access
>> to them, particularly if they're setuid or similar, they have access to
>> those old and now known vulns in setuid executables! (Of course users
>> can grab vulnerable versions elsewhere or build them themselves, but they
>> can't set them setuid root unless they /are/ root, so finding an existing
>> setuid-root executable with known vulns is finding the keys to the
>> kingdom.)
>>
>> So keeping snapshots unmounted and out of the normally accessible
>> filesystem tree by default is recommended, at least if you're at all
>> concerned about someone untrusted getting access to a normal user account
>> and being able to use snapshots with known vulns of setuid executables as
>> root-escalation methods.
>>
>> Another possibility is setting the snapshot subdir 700 perms, so non-
>> super-users can't normally access anything in it anyway. Of course
>> that's a problem if you want them to have access to snapshots of their
>> own stuff for recovery purposes, but it's useful if you can do it.
>>
>> Good admins will do both of these at once if possible as they know and
>> observe the defense-in-depth mantra, knowing all too well how easy a
>> single layer of defense yields to fat-fingering or previously unknown
>> vulns.
>>
>> --
>> 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
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> Thank you, Duncan. I will try to take all that into consideration.
> These are really just fairly simple personal home systems, but
> security is still important.
On the note of the old binaries and libraries bit, nodev, noexec, and
nosuid are all per-mountpoint, not per-volume, so you can mitigate some
of the rsik by always mounting with those flags. Despite that, it's
still a good idea to not have anything more than you need mounted at any
given time (it's a lot harder to screw up a filesystem which isn't mounted).
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Confusion about snapshots containers
2017-03-29 21:27 Confusion about snapshots containers Tim Cuthbertson
2017-03-29 21:55 ` Hugo Mills
@ 2017-03-31 17:40 ` Kai Krakow
1 sibling, 0 replies; 7+ messages in thread
From: Kai Krakow @ 2017-03-31 17:40 UTC (permalink / raw)
To: linux-btrfs
Am Wed, 29 Mar 2017 16:27:30 -0500
schrieb Tim Cuthbertson <ratcheer@gmail.com>:
> I have recently switched from multiple partitions with multiple
> btrfs's to a flat layout. I will try to keep my question concise.
>
> I am confused as to whether a snapshots container should be a normal
> directory or a mountable subvolume. I do not understand how it can be
> a normal directory while being at the same level as, for example, a
> rootfs subvolume. This is with the understanding that the rootfs is
> NOT at the btrfs top level.
>
> Which should it be, a normal directory or a mountable subvolume
> directly under btrfs top level? If either way can work, what are the
> pros and cons of each?
I think there is no exact standard you could follow. Many distributions
seems to go for the standard to prepend subvolumes with "@" if they are
meant to be mounted. However, I'm not doing so.
Generally speaking, subvolumes organize your volume into logical
containers which make sense to be snapshotted on their own. Snapshots
won't propagate to sub-subvolumes, it is important to keep that in mind
while designing your idea of a structure.
I'm using it like this:
In subvol=0 I have the following subvolumes:
/* - contains distribution specific file systems
/home - contains home directories
/snapshots - contains snapshots I want to keep
/other
- misc stuff, i.e. a dump of the subvol structure in a txt
- a copy of my restore script
- some other supporting docs for restore
- this subvolume is kept in sync with my backup volume
This means: If I mount one of the rootfs, my home will not be part of
this mount automatically because that subvolume is out of scope of the
rootfs.
Now I have the following subvolumes below these:
/gentoo/rootfs - rootfs of my main distribution
Note 1: Everything below (except subvolumes) should be maintained
by the package manager.
Note 2: currently I installed no other distributions
Note 3: I could have called it main-system-rootfs
/gentoo/usr
- actually not a subvolume but a directory for volumes shareable with
other distribution instances
/gentoo/usr/portage - portage, shareable by other gentoo instances
/gentoo/usr/src - the gentoo linux kernel sources, shareable
The following are put below /gentoo/rootfs so they not need to be
mounted separately:
/gentoo/rootfs/var/log
- log volume because I don't want it to be snapshotted
/gentoo/rootfs/var/tmp
- tmp volume because it makes no sense to be snapshotted
/gentoo/rootfs/var/lib/machines
- subvolume for keeping nspawn containers
/gentoo/rootfs/var/lib/machines/*
- different machines cloned from each other
/gentoo/rootfs/usr/local
- non-package manager stuff
/home/myuser - my user home
/home/myuser/.VirtualBox
- VirtualBox machines because I want them snapshotted separately
/etc/fstab now only mounts subvolumes outside of the scope
of /gentoo/rootfs:
LABEL=system /home btrfs compress=lzo,subvol=home,noatime
LABEL=system /usr/portage btrfs noauto,compress=lzo,subvol=gentoo/usr/portage,noatime,x-systemd.automount
LABEL=system /usr/src btrfs noauto,compress=lzo,subvol=gentoo/usr/src,noatime,x-systemd.automount
Additionally, I mount the subvol=0 for two special purposes:
LABEL=system /mnt/btrfs-pool btrfs noauto,compress=lzo,subvolid=0,x-systemd.automount,noatime
First: For managing all the subvolumes and have an untampered view
(without tmpfs or special purpose mounts) to the volumes.
Second: To take a clean backup of the whole system.
Now, I can give the bootloader subvol=gentoo/rootfs to select which
system to boot (or make it the default subvolume).
Maybe you get the idea and find that idea helpful.
PS: It can make sense to have var/lib/machines outside of the rootfs
scope if you want to share it with other distributions.
--
Regards,
Kai
Replies to list-only preferred.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2017-03-31 17:44 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-03-29 21:27 Confusion about snapshots containers Tim Cuthbertson
2017-03-29 21:55 ` Hugo Mills
2017-03-29 23:20 ` Fwd: " Tim Cuthbertson
2017-03-30 3:46 ` Duncan
2017-03-30 13:07 ` Tim Cuthbertson
2017-03-31 11:34 ` Austin S. Hemmelgarn
2017-03-31 17:40 ` Kai Krakow
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.