On 2017-02-03 04:14, Duncan wrote:
Graham Cobb posted on Thu, 02 Feb 2017 10:52:26 +0000 as excerpted:
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.
Read-only *after* completion, yes. But a sysadmin that believes really
setting something read-only and then trying to write to it from
userspace, which is what btrfs does until the receive is done, should
work, doesn't understand the meaning of read-only.
Meanwhile, Austin said most of what I'd say, probably better than I'd say
it, so I won't repeat it here, but I agree with him.
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.
One thing I was going to say in the previous post and forgot, is that not
withstanding all the technical reasons, I do agree that documenting it in
the manpage, etc, would be a good idea. In that I agree with both you
and Austin. =:^)
I can look at making a patch for this, but it may be next week before I
have time (I'm not great at multi-tasking when it comes to software
development, and I'm in the middle of helping to fix a bug in Ansible
right now).
--
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
