Re: [RFC] Improve subvolume usability for a normal user

[Graham Cobb <g.btrfs@cobb.uk.net>]

On 05/12/17 12:41, Austin S. Hemmelgarn wrote:
> On 2017-12-05 03:43, Qu Wenruo wrote:
>>
>>
>> On 2017年12月05日 16:25, Misono, Tomohiro wrote:
>>> Hello all,
>>>
>>> I want to address some issues of subvolume usability for a normal user.
>>> i.e. a user can create subvolumes, but
>>>   - Cannot delete their own subvolume (by default)
>>>   - Cannot tell subvolumes from directories (in a straightforward way)
>>>   - Cannot check the quota limit when qgroup is enabled
>>>
>>> Here I show the initial thoughts and approaches to this problem.
>>> I want to check if this is a right approach or not before I start
>>> writing code.
>>>
>>> Comments are welcome.
>>> Tomohiro Misono
>>>
>>> ==========
>>> - Goal and current problem
>>> The goal of this RFC is to give a normal user more control to their
>>> own subvolumes.
>>> Currently the control to subvolumes for a normal user is restricted
>>> as below:
>>>
>>> +-------------+------+------+
>>> |   command   | root | user |
>>> +-------------+------+------+
>>> | sub create  | Y    | Y    |
>>> | sub snap    | Y    | Y    |
>>> | sub del     | Y    | N    |
>>> | sub list    | Y    | N    |
>>> | sub show    | Y    | N    |
>>> | qgroup show | Y    | N    |
>>> +-------------+------+------+
>>>
>>> In short, I want to change this as below in order to improve user's
>>> usability:
>>>
>>> +-------------+------+--------+
>>> |   command   | root | user   |
>>> +-------------+------+--------+
>>> | sub create  | Y    | Y      |
>>> | sub snap    | Y    | Y      |
>>> | sub del     | Y    | N -> Y |
>>> | sub list    | Y    | N -> Y |
>>> | sub show    | Y    | N -> Y |
>>> | qgroup show | Y    | N -> Y |
>>> +-------------+------+--------+
>>>
>>> In words,
>>> (1) allow deletion of subvolume if a user owns it, and
>>> (2) allow getting subvolume/quota info if a user has read access to it
>>>   (sub list/qgroup show just lists the subvolumes which are readable
>>> by the user)
>>>
>>> I think other commands not listed above (qgroup limit, send/receive
>>> etc.) should
>>> be done by root and not be allowed for a normal user.
>>>
>>>
>>> - Outside the scope of this RFC
>>> There is a qualitative problem to use qgroup for limiting user disk
>>> amount;
>>> quota limit can easily be averted by creating a subvolume. I think
>>> that forcing
>>> inheriting quota of parent subvolume is a solution, but I won't
>>> address nor
>>> discuss this here.
>>>
>>>
>>> - Proposal
>>>   (1) deletion of subvolume
>>>
>>>    I want to change the default behavior to allow a user to delete
>>> their own
>>>    subvolumes.
>>>       This is not the same behavior as when user_subvol_rm_alowed
>>> mount option is
>>>    specified; in that case a user can delete the subvolume to which
>>> they have
>>>    write+exec right.
>>>       Since snapshot creation is already restricted to the subvolume
>>> owner, it is
>>>    consistent that only the owner of the subvolume (or root) can
>>> delete it.
>>>       The implementation should be straightforward.
>>
>> Personally speaking, I prefer to do the complex owner check in user
>> daemon.
>>
>> And do the privilege in user daemon (call it btrfsd for example).
>>
>> So btrfs-progs will works in 2 modes, if root calls it, do as it used
>> to do.
>> If normal user calls it, proxy the request to btrfsd, and btrfsd does
>> the privilege checking and call ioctl (with root privilege).
>>
>> Then no impact to kernel, all complex work is done in user space.
> Exactly how hard is it to just check ownership of the root inode of a
> subvolume from the ioctl context?  You could just as easily push all the
> checking out to the VFS layer by taking an open fd for the subvolume
> root (and probably implicitly closing it) instead of taking a path, and
> that would give you all the benefits of ACL's and whatever security
> modules the local system is using.  

+1 - stop inventing new access control rules for each different action!