Graham Cobb posted on Wed, 01 Feb 2017 22:51:34 +0000 as excerpted: >> [C]ouldn'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.
If it's a workaround, then many of the Linux procedures we as admins and users use every day are equally workarounds. Setting 007 perms on a dir that doesn't have anything immediately security vulnerable in it, simply to keep other users from even potentially seeing or being able to write to something N layers down the subdir tree, is standard practice. Which is my point. This is no different than standard security practice, that an admin should be familiar with and using without even having to think about it. Btrfs is simply making the same assumptions that everyone else does, that an admin knows what they are doing and sets the upstream permissions with that in mind. If they don't, how is that btrfs' fault? -- 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
