Graham Cobb posted on Wed, 01 Feb 2017 17:43:32 +0000 as excerpted: > 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.
I'll prefix this question by noting that my own use-case doesn't use send/ receive, so while I know about it in general from following the list, I've no personal experience with it... With that said, couldn't the entire problem be eliminated by properly setting the permissions on a directory/subvol upstream of the received snapshot? If said upstream parent is only readable/enterable by root (or some specific user), then one would have to be root or that user in ordered to interfere, as nobody else could even get to the receiving snapshot to commit mayhem. IOW, it should work like directory permissions have always worked. If you don't have enter access to the parent, you can't read/write the child, thus no need for btrfs-receive specific permission-hoop-jumping. (And of course SELinux or similar could be used to tighten permissions even further, should that be justified by the use-case.) -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
