On 2017-02-05 06:54, Kai Krakow wrote:
Am Wed, 1 Feb 2017 17:43:32 +0000
schrieb Graham Cobb <g.btrfs@xxxxxxxxxxx>:
On 01/02/17 12:28, Austin S. Hemmelgarn wrote:
On 2017-02-01 00:09, Duncan wrote:
Christian Lupien posted on Tue, 31 Jan 2017 18:32:58 -0500 as
excerpted:
[...]
I'm just a btrfs-using list regular not a dev, but AFAIK, the
behavior is likely to be by design and difficult to change,
because the send stream is simply a stream of userspace-context
commands for receive to act upon, and any other suitably
privileged userspace program could run the same commands. (If
your btrfs-progs is new enough receive even has a dump option,
that prints the metadata operations in human readable form, one
operation per line.)
So making the receive snapshot read-only during the transfer would
prevent receive itself working.
That's correct. Fixing this completely would require implementing
receive on the kernel side, which is not a practical option for
multiple reasons.
I am with Christian on this. Both the effects he discovered go against
my expectation of how send/receive would or should work.
This first bug is more serious because it appears to allow a
non-privileged user to disrupt the correct operation of receive,
creating a form of denial-of-service of a send/receive based backup
process. If I decided that I didn't want my pron collection (or my
incriminating emails) appearing in the backups I could just make sure
that I removed them from the receive snapshots while they were still
writeable.
You may be right that fixing this would require receive in the kernel,
and that is undesirable, although it seems to me that it should be
possible to do something like allow receive to create the snapshot
with a special flag that would cause the kernel to treat it as
read-only to any requests not delivered through the same file
descriptor, or something like that (or, if that can't be done, at
least require root access to make any changes). In any case, I
believe it should be treated as a bug, even if low priority, with an
explicit warning about the possible corruption of receive-based
backups in the btrfs-receive man page.
How about mounting the receiver below a directory only traversable by
root (chmod og-rwx)? Backups shouldn't be directly accessible by
ordinary users anyway.
There are perfectly legitimate reasons to have backups directly
accessible by users. If you're running automated backups for _their_
systems _they_ absolutely should have at least read access to the
backups _once they're stable_. This is not a common case, but it is a
perfectly legitimate one. In the same way, if you're storing backups
for your users (in this case you absolutely should not be4 using
send/receive for other reasons), then the use case dictates that they
have some way to access them.
If you want a backup becoming accessible, you can later snapshot it to
an accessible location after send/receive finished without errors.
An in-transit backup, however, should always be protected from possible
disruptive access. This is an issue with any backup software. So place
the receive within an inaccessible directory. This is not something the
backup process should directly bother with for simplicity.
I agree on this point however. Doing a backup directly into the final
persistent storage location is never a good idea. It makes error
handling more complicated, it makes handling of multi-tier storage more
complicated (and usually less efficient), and it makes security more
difficult.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
