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 have been testing btrfs send/receive. I like it. >>> >>> During those tests I discovered that it is possible to access and modify >>> (add files, delete files ...) of the new receive snapshot during the >>> transfer. After the transfer it becomes readonly but it could already >>> have been modified. >>> >>> So you can end up with a source and a destination which are not the >>> same. Therefore during a subsequent incremental transfers I can get >>> receive to crash (trying to unlink a file that is not in the parent but >>> should). >>> >>> Is this behavior by design or will it be prevented in the future? >>> >>> I can of course just not modify the subvolume during receive but is >>> there a way to make sure no user/program modifies it? >> >> 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. >>> I can also get in the same kind of trouble by modifying a parent (after >>> changing its property temporarily to ro=false). send/receive is checking >>> that the same parent uuid is available on both sides but not that >>> generation has not changed. Of course in this case it requires direct >>> user intervention. Never changing the ro property of subvolumes would >>> prevent the problem. >>> >>> Again is this by design? >> >> Again, yes. The ability to toggle snapshots between ro/rw is a useful >> feature and was added deliberately. This one would seem to me to be much >> like the (no doubt apocryphal) guy who went to the doctor complaining >> that when he beat his head against the wall, it hurt. The doctor said, >> "Stop doing that then." > Agreed, especially considering that some of the most interesting > use-cases for send/receive (which requires the sent subvolume to be > read-only) require the subvolume to be made writable again on the other > end. I agree that there are good reasons why subvolumes should be switchable between ro and rw. However, receive should detect and issue warnings when this problem has happened (for example by checking the generation). Again, this may be low priority, and may need to wait for a send stream format change, but it can't be claimed that this is correct behaviour. Graham -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
