[RFC v2] Improve subvolume usability for a normal user

[RFC v2] Improve subvolume usability for a normal user

[Misono, Tomohiro]

Hello all,

I reflected the comments of the first version of the RFC[1]. 
Thanks for all those who commented.

The summary of updated proposal is:
 - Change the default behavior to allow a user to delete subvolume which is empty
 - Add 2 new non-root ioctls to get subvolume/quota info under the specified path

Please see the 'Proposal' section below for the detail.

More comments are welcome.
Regards,
Tomohiro Misono

[1] https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg70666.html

==========
- 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 it is empty) and
(2) allow getting subvolume/quota info (under the specified path)

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.


- Proposal
 (1) deletion of subvolume

  Change the default behavior for a user to allow to delete a subvolume (by "subvol del") if 
    1. the user has write+exec right to it, and
    2. it is empty
  So, it is the same as user_subvol_rm_allowed option with emptiness check.

  Emptiness check is needed because Snapshot creation wont' check the permission and 
  can copy a dir which cannot be deleted by the user, and therefore just allowing deletion 
  may cause data loss.

  Summary of behavior by different condition is as follows:

  +===============================+========================+======================+
  |                               |        Current         |       Proposal       |
  +===============================+========================+======================+
  | root                          | Can delete all         | Same as the current  |
  +-------------------------------+------------------------+----------------------+
  | user (user_subvol_rm_allowed) | Can delete if he       | Same as the current  |
  |                               | has write+exec right   |                      |
  +-------------------------------+------------------------+----------------------+
  | user (default)                | Cannot delete anything | Can delete if he     |
  |                               |                        | has write+exec right |
  |                               |                        | and is empty         |
  +-------------------------------+------------------------+----------------------+
 
 (2) getting subvolume/quota info

  Introduce 2 new ioctls to get subol/quota info under the specified path (which needs
  to be able to be opened by the user) and modify INO_LOOKUP to check permission
  during path construction for a normal user. 

  Current approach cannot be used directly for a normal user as explained below:
    TREE_SEARCH ioctl is used to retrieve the subvolume/quota info by btrfs-progs
    (sub show/list, qgroup show etc.). This requires the root permission. Also, 
    in order to construct the path, INO_LOOKUP will be called afterwards,\v which also
    requires root permission and omits the permission check during path construction.
  
    The easiest way to allow a user to get subvolume/quota info is just relaxing
    the permission of TREE_SEARCH. However, since all the tree information (inc.
    file name) will be exposed, this poses a sequrity risk and is not acceptable.
 
  The detail of new ioctls and approach is here:
   [subvolume info]
    Searching ROOT tree for ROOT_ITEM/ROOT_BACKREF under the specified path, and 
    checking its read right by searching FS/FILE tree and comparing the mode with caller's uid.
    
    After this ioctl is called, btrfs-progs calls modified INO_LOOKUP to construct the path
    with permission check. In case path construction fails due to permission, btrfs-progs
    skips to output the infomation of the subvolume.
  
   [quota info]
    Same as above, but mainly searching QUOTA tree.


- Summary of Proposal
 - Change the default behavior to allow a user to delete subvolume which is empty
 - Add 2 new non-root ioctls to get subvolume/quota info under the specified path
==========

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

[ein]

On 12/11/2017 07:38 AM, Misono, Tomohiro wrote:
> - Change the default behavior to allow a user to delete subvolume which is empty

>From sysadmin point of view I think it's worth considering the following
scenario(s):
what if admin wants one persistent snapshot undeletable by the user?
- snapshots created by the root in user work tree should not be deleted
by the user (snapshot owner should be root?), but we may want also
permissions, filesystem ACLs and extend ACLs consistency
- snapshots with chattr +i should be not deleted by the user, even if he
created it.

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

[ein]

And also, how to prevent creation of the snapshots by the user.

On 12/11/2017 08:30 AM, ein wrote:
> On 12/11/2017 07:38 AM, Misono, Tomohiro wrote:
>> - Change the default behavior to allow a user to delete subvolume which is empty
> From sysadmin point of view I think it's worth considering the following
> scenario(s):
> what if admin wants one persistent snapshot undeletable by the user?
> - snapshots created by the root in user work tree should not be deleted
> by the user (snapshot owner should be root?), but we may want also
> permissions, filesystem ACLs and extend ACLs consistency
> - snapshots with chattr +i should be not deleted by the user, even if he
> created it.

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

[Misono, Tomohiro]

Hello,

On 2017/12/11 16:30, ein wrote:
> On 12/11/2017 07:38 AM, Misono, Tomohiro wrote:
>> - Change the default behavior to allow a user to delete subvolume which is empty
> 
> From sysadmin point of view I think it's worth considering the following
> scenario(s):
> what if admin wants one persistent snapshot undeletable by the user?
> - snapshots created by the root in user work tree should not be deleted
> by the user (snapshot owner should be root?), but we may want also
> permissions, filesystem ACLs and extend ACLs consistency
> - snapshots with chattr +i should be not deleted by the user, even if he
> created it.
> --
Immutable flag is already supported. So, we can set +i recursively by "sudo chattr -R +i <snapshot>"
If Immutable flag is set, it cannot be deleted by even root and it cannot be set/dropped by a normal user.