Re: Qgroups are not applied when snapshotting a subvol?

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

Chris Murphy posted on Mon, 27 Mar 2017 15:11:34 -0600 as excerpted:

>> What are actual use cases for creating subvolumes by 'normal' users?
>>
>> Does someone have an example?
>>
>> Why is it possible at all, by default?
> 
> I have a single git subvolume in my user directory, inside of which are
> various git clones. And I periodically snapshot the git subvolume as a
> regular user.
> 
> If I can't create subvolumes as a regular user then by extension it'd
> mean I can't create snapshots of my own home directory, or any other
> subvolumes I exclusively own.

One rather big problem with what, with snapshots (which are a special 
kind of subvolume), is that btrfs has known scaling issues when the 
number of snapshots gets too high.  Combine that with allowing users to 
make but not delete snapshots, and you have a huge invitation to scaling 
headaches due to the number of snapshots.

Really, the two permissions subvolume/snapshot creation, and deletion, 
should be synchronized.  Allowing subvolume deletion clearly has security 
issues, but so does allowing creation without allowing deletion.  They 
both really have to go together, and be allowed only for "trusted" users, 
with the option of whether that's root-only, or a subset of users (say 
via group perms), or all users, being up to the local admin, basically, a 
mount option.

Which in usual terms means making the perms root-only, with the binary 
set to some controlled-access group and set-SUID-root (or appropriate 
security attributes, I'm drawing a blank on the word I want ATM), and 
then letting the admin control access via group membership.

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