Re: btrfs receive leaves new subvolume modifiable during operation

[Duncan <1i5t5.duncan@cox.net>]

Graham Cobb posted on Wed, 01 Feb 2017 22:51:34 +0000 as excerpted:

>> [C]ouldn't the entire problem be eliminated by properly
>> setting the permissions on a directory/subvol upstream of the received
>> snapshot?
> 
> I (honestly) don't know. But even if that does work, it is clearly only
> a workround for the bug. Where in the documentation does it warn the
> system manager about the problem? Where does it tell them that they had
> better make sure they only receive into a directory tree which does not
> allow users read or execute access (not just not write access!)? What if
> part of the point of the backup strategy is that user's have read access
> to these snapshots so they can restore their own files?
> 
> The possibility of a knowledgeable system manager being able to
> workround the problem by limiting how they use it doesn't stop it being
> a bug.

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.

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?

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman