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.