Re: btrfs receive leaves new subvolume modifiable during operation

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

On 2017-02-02 05:52, Graham Cobb wrote:
> 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.
That depends on the admin.  I for example would absolutely expect that 
to be needed _while the snapshot is being created_ if the operation 
isn't being done by the kernel.
>
>> 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.
If that's your use case, then from a consistency perspective, you should 
be receiving into a location the user can't read and then moving the 
subvolume into a user readable location once receive is done anyway. 
Otherwise, they may see a partial snapshot, and think something has been 
deleted that really hasn't.  This is a pretty basic method of ensuring 
consistency that's used literally all over the place on UNIX systems to 
atomically replace or update data sets.  Doing so also cleanly avoids 
needing to manipulate permissions on the directory the snapshots are in 
to prevent users from modifying the snapshots being received.
>
> 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.
I agree that it should be documented.  I don't agree that a specific 
workaround needs to be stated, as whether or not any particular 
workaround is needed is entirely dependent on the use case.  For 
example, if your users can only access the received snapshots over a 
networked filesystem, there's a much simpler option of just exporting 
the directories the snapshots are received into as read-only.  All that 
needs to be stated is that the way to prevent this is to make sure users 
can't write to the snapshots while they're being received.