Re: btrfs receive leaves new subvolume modifiable during operation

["Austin S. Hemmelgarn" <ahferroin7@gmail.com>]

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).