On 2018年05月16日 13:49, Tomohiro Misono wrote: > [based on current misc-next] > > changelog: > v4 -> v5 > - Update error handling of 1st/2nd patch. See each log for details > - Fix misspelling > v3 -> v4 > - call btrfs_next_leaf() after btrfs_search_slot() when the slot > position exceeds the number of items > - rebased to current misc-next > v2 -> v3 > - fix kbuild test bot warning > v1 -> v2 > - completely reimplement 1st/2nd ioctl to have user friendly api > - various cleanup, remove unnecessary goto > === > > This adds three new unprivileged ioctls: > > 1st patch: > ioctl which returns subvolume information of ROOT_ITEM and ROOT_BACKREF > 2nd patch: > ioctl which returns subvolume information of ROOT_REF (without subvolume > name)
First 2 patches looks mostly fine. > 3rd patch: > user version of ino_lookup ioctl which also performs permission check. I'm a little concerned about this. What will happen in the following scenario? - Environment is container whose rootfs is a subvolume of btrfs - The root and normal use try to call subvolume list on their rootfs Will it leak the real subvolume layout to the container root/normal user? Or it will leak anyway even without the unprivileged ioctl? Thanks, Qu > > They will be used to implement user version of "subvolume list/show" etc. > in user tools. > See each commit log for more detals. > > The implementation of btrfs-progs can be found in the ML titled as follows: > [PATCH 0/11] btrfs-progs: Rework of "subvolume list/show" and relax the > root privileges of them > > Tomohiro Misono (3): > btrfs: Add unprivileged ioctl which returns subvolume information > btrfs: Add unprivileged ioctl which returns subvolume's ROOT_REF > btrfs: Add unprivileged version of ino_lookup ioctl > > fs/btrfs/ioctl.c | 452 > +++++++++++++++++++++++++++++++++++++++++++++ > include/uapi/linux/btrfs.h | 84 +++++++++ > 2 files changed, 536 insertions(+) >
signature.asc
Description: OpenPGP digital signature
