Re: Qgroups are not applied when snapshotting a subvol?

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

Austin S. Hemmelgarn posted on Tue, 28 Mar 2017 07:44:56 -0400 as
excerpted:

> On 2017-03-27 21:49, Qu Wenruo wrote:

>> The problem is, how should we treat subvolume.
>>
>> Btrfs subvolume sits in the middle of directory and (logical) volume
>> used in traditional stacked solution.
>>
>> While we allow normal user to create/delete/modify dir as long as they
>> follow access control, we require privilege to create/delete/modify
>> volumes.

> No, we require privilege to do certain modifications or delete
> subvolumes.

>  Regular users can create subvolumes with no privileges whatsoever, and
> most basic directory operations (rename, chown, chmod, etc) work just
> fine within normal UNIX DAC permissions.  Unless you're running some
> specially patched kernel or some LSM (SELinux possibly) that somehow
> restricts access to the ioctl, you can always create subvolumes.

(I believe) You misread what QW was trying to say. Note the word "volume" 
as opposed to subvolume.  Like most regulars here, Qu's too deep into 
btrfs to make that sort of mistake, so he wasn't talking about subvolumes.

Rather, he's placing btrfs subvolumes in the middle between directories 
and (generic/logical) volumes as normally used, and saying that for 
(generic) directories normal users can create/modify/delete without 
special privilege (beyond write in the parent), for (generic) volumes 
special privileges are necessary to create/modify/delete, and btrfs 
subvolumes fall in between, so there's a real decision to be made in 
terms of privileges required, do they follow directories and require 
nothing special or volumes and require special privs?


Meanwhile, my own position as I've argued is that regardless of the 
theoretical debate, as long as we have the very real practical issue of 
hard scaling issues for subvolumes/snapshots, there's an equally real 
security issue in allowing unrestricted snapshot and to a lessor extent 
normal subvolume creation.

So while we might /like/ to make subvolumes more like directories and 
require no special privs, until the snapshot scaling and thus security 
issue is fixed or at least greatly reduced, as a purely practical 
security matter, we really need to restrict snapshot creation to 
privileged users.

OTOH, it's worth pointing out that snapshots aren't unique in this 
regard, reflinked files have exactly the /same/ scaling issues except 
their one-by-one while snapshots tend to be a whole bunch of reflinked 
files at once.

Which means the question must then be asked, if we choose the privileged 
route for snapshots/subvolumes due to the reflinking security issues, why 
aren't we making all reflinking ops privileged ops, or should we?  If we 
did, cp --reflink=always, among other things, would obviously fail as a 
normal user.

So I guess it's a rather harder question than I considered at first.  
Maybe we /should/ just treat subvolumes as directories in privileges 
terms as well.  In that case, however, we really need to have the same 
default for subvolume deletion as creation.

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