On 01/02/17 22:27, Duncan wrote: > 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? I (honestly) don't know. But even if that does work, it is clearly only a workround for the bug. Where in the documentation does it warn the system manager about the problem? Where does it tell them that they had better make sure they only receive into a directory tree which does not allow users read or execute access (not just not write access!)? What if part of the point of the backup strategy is that user's have read access to these snapshots so they can restore their own files? The possibility of a knowledgeable system manager being able to workround the problem by limiting how they use it doesn't stop it being a bug. -- 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
