Re: Qgroups are not applied when snapshotting a subvol?

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

On 2017-03-29 01:38, Duncan wrote:
> 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.
Ah, you're right, I need to quit reading so fast all the time :)
>
> 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.
There is a bigger issue though in that subvolumes are a resource a 
regular user can create but not destroy and there is no way to limit the 
number a user can create.  This is never a good situation to be in, but 
it appears to have arisen because there are no proper privilege checks 
on subvolume deletion, just the 'are you EUID 0?' thing.  The ioctl 
should require some proof that you could delete the subvolume if it were 
a directory, then we could get rid of the whole 'user_subvol_rm_allowed' 
thing and move on a bit more sensibly.
>
> 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.
Snapshots and reflinks have scaling issues on every filesystem I've seen 
that supports them internally that isn't inherently log structured.  The 
scaling issue is far worse on BTRFS than most others, but it's by no 
means unique to BTRFS.
>
> 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.
Normal users should be able to use reflinks.  That is the expectation 
set forth by BTRFS already, as well as other filesystems which support 
reflinks.
>
> 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.
>