On 02/02/17 00:02, Duncan wrote: > 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.
No. There is no need to normally place a read-only snapshot below a no-execute directory just to prevent write access to it. That is not part of the admin's expectation. > 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? Because btrfs intends the receive snapshot to be read-only. That is the expectation of the sysadmin. It is an important and useful feature which makes send/receive very useful for creating user-readable-but-not-modifiable backups (without it, send/receive are useful for many things but less useful for creating backups). That feature has a bug. Just because you don't personally use the feature, doesn't mean it isn't a bug! Many of us do rely on that feature. Even though it is security-related, I agree it isn't the highest priority btrfs bug. It can probably wait until receive is being worked on for other reasons. But if it isn't going to be fixed any time soon, it should be documented in the Wiki and the man page, with the suggested workround for anyone who needs to make sure the receive won't be tampered with. -- 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
