Re: btrfs receive leaves new subvolume modifiable during operation

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

Graham Cobb posted on Wed, 01 Feb 2017 17:43:32 +0000 as excerpted:

> This first bug is more serious because it appears to allow a
> non-privileged user to disrupt the correct operation of receive,
> creating a form of denial-of-service of a send/receive based backup
> process. If I decided that I didn't want my pron collection (or my
> incriminating emails) appearing in the backups I could just make sure
> that I removed them from the receive snapshots while they were still
> writeable.

I'll prefix this question by noting that my own use-case doesn't use send/
receive, so while I know about it in general from following the list, 
I've no personal experience with it...

With that said, couldn't the entire problem be eliminated by properly 
setting the permissions on a directory/subvol upstream of the received 
snapshot?  If said upstream parent is only readable/enterable by root (or 
some specific user), then one would have to be root or that user in 
ordered to interfere, as nobody else could even get to the receiving 
snapshot to commit mayhem.

IOW, it should work like directory permissions have always worked.  If 
you don't have enter access to the parent, you can't read/write the 
child, thus no need for btrfs-receive specific permission-hoop-jumping.  
(And of course SELinux or similar could be used to tighten permissions 
even further, should that be justified by the use-case.)

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