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! -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
