From: Brendan Hide <brendan@swiftspirit.co.za>
To: Chris Murphy <lists@colorremedies.com>, kreijack@inwind.it
Cc: Chris Mason <clm@fb.com>,
systemd-devel@lists.freedesktop.org,
linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec
Date: Thu, 13 Mar 2014 01:22:45 +0200 [thread overview]
Message-ID: <5320EC45.70803@swiftspirit.co.za> (raw)
In-Reply-To: <F34652FB-331F-4BA7-A2D9-35C3DE7B770D@colorremedies.com>
On 2014/03/12 09:31 PM, Chris Murphy wrote:
> On Mar 12, 2014, at 1:12 PM, Goffredo Baroncelli <kreijack@inwind.it> wrote:
>> On 03/12/2014 06:24 PM, Chris Mason wrote:
> Your suggestion also sounds like it places snapshots outside of their parent subvolume? If so it mitigates a possible security concern if the snapshot contains (old) binaries with vulnerabilities. I asked about how to go about assessing this on the Fedora security list:
> https://lists.fedoraproject.org/pipermail/security/2014-February/001748.html
>
> There aren't many replies but the consensus is that it's a legitimate concern, so either the snapshots shouldn't be persistently available (which is typical with e.g. snapper, and also yum-plugin-fs-snapshot), and/or when the subvolume containing snapshots is mounted, it's done with either mount option noexec or nosuid (no consensus on which one, although Gnome Shell uses nosuid by default when automounting removable media).
This is exactly the same result if following the previously-recommended
subvolume layout given on the Arch wiki. It seems this wiki advice has
"disappeared" so I can't give a link for it ...
My apologies if the rest of my mail is off-topic.
Though not specifically for rollback, my snapshots prior to btrfs {send
| , receive} backup is done via temporary mountpoint. Until two days ago
I was still using rsync to a secondary btrfs volume and the __snapshots
folder had been sitting empty for about a year. The performance
difference with send|receive is magnitudes apart: A daily backup to the
secondary disk now takes between 30 and 40 seconds whereas it took 20 to
30 minutes with rsync.
Here are my current subvolumes:
__active
__active/home
__active/usr
__active/var
__snapshots/__2014-03-12-23h00m01s+0200
__snapshots/_home_2014-03-12-23h00m01s+0200
__snapshots/_usr_2014-03-12-23h00m01s+0200
__snapshots/_var_2014-03-12-23h00m01s+0200
I hadn't thought of noexec or nosuid. On a single-user system you don't
really expect that type of incursion. I will put up my work after I've
properly automated cleanup.
The only minor gripe I have with the temporary mount is that I feel it
should be possible to perform snapshots and use send|receive without the
requirement of having the subvolumes be "visible" in userspace.
--
__________
Brendan Hide
http://swiftspirit.co.za/
http://www.webafrica.co.za/?AFF1E97
next prev parent reply other threads:[~2014-03-12 23:34 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20140307182603.GA22874@tango.0pointer.de>
2014-03-10 18:34 ` [systemd-devel] [HEADS-UP] Discoverable Partitions Spec Goffredo Baroncelli
2014-03-10 18:53 ` Kay Sievers
2014-03-10 18:59 ` Goffredo Baroncelli
2014-03-10 19:43 ` Chris Murphy
2014-03-10 20:02 ` Lennart Poettering
2014-03-10 20:21 ` Chris Mason
2014-03-10 20:53 ` Chris Murphy
2014-03-10 21:09 ` Lennart Poettering
2014-03-10 22:44 ` Goffredo Baroncelli
2014-03-10 22:39 ` Goffredo Baroncelli
2014-03-10 23:45 ` Lennart Poettering
2014-03-10 23:59 ` Alex Elsayed
2014-03-11 14:30 ` [systemd-devel] " Calvin Walton
2014-03-12 17:24 ` Chris Mason
2014-03-12 19:12 ` Goffredo Baroncelli
2014-03-12 19:31 ` Chris Murphy
2014-03-12 19:55 ` Goffredo Baroncelli
2014-03-12 23:22 ` Brendan Hide [this message]
2014-03-12 22:18 ` Goffredo Baroncelli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5320EC45.70803@swiftspirit.co.za \
--to=brendan@swiftspirit.co.za \
--cc=clm@fb.com \
--cc=kreijack@inwind.it \
--cc=linux-btrfs@vger.kernel.org \
--cc=lists@colorremedies.com \
--cc=systemd-devel@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.