Re: btrfs receive leaves new subvolume modifiable during operation

["Austin S. Hemmelgarn" <ahferroin7@gmail.com>]

On 2017-02-05 06:54, Kai Krakow wrote:
> Am Wed, 1 Feb 2017 17:43:32 +0000
> schrieb Graham Cobb <g.btrfs@cobb.uk.net>:
>
>> 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.