RE: [PATCH RESEND 0/8] btrfs-progs: sub: Relax the privileges of "subvolume list/show"

["misono.tomohiro@fujitsu.com" <misono.tomohiro@fujitsu.com>]

> -----Original Message-----
> From: Omar Sandoval [mailto:osandov@osandov.com]
> Sent: Friday, December 7, 2018 10:02 AM
> To: Misono, Tomohiro/味曽野 智礼 <misono.tomohiro@fujitsu.com>
> Cc: linux-btrfs@vger.kernel.org
> Subject: Re: [PATCH RESEND 0/8] btrfs-progs: sub: Relax the privileges of
> "subvolume list/show"
> 
> On Tue, Nov 27, 2018 at 02:24:41PM +0900, Misono Tomohiro wrote:
> > Hello,
> >
> > This is basically the resend of
> >   "[PATCH v2 00/20] btrfs-progs: Rework of "subvolume list/show" and relax
> the
> > 	root privileges of them" [1]
> > which I submitted in June. The aim of this series is to allow non-privileged
> user
> > to use basic subvolume functionality (create/list/snapshot/delete; this
> allows "list")
> >
> > They were once in devel branch with some whitespace/comment modification by
> david.
> > I rebased them to current devel branch.
> >
> > github: https://github.com/t-msn/btrfs-progs/tree/rework-sub-list
> >
> > Basic logic/code is the same as before. Some differences are:
> >  - Use latest libbtrfsutil from Omar [2] (thus drop first part of patches).
> >    As a result, "sub list" cannot accept an ordinary directry to be
> >    specified (which is allowed in previous version)
> >  - Drop patches which add new options to "sub list"
> >  - Use 'nobody' as non-privileged test user just like libbtrfsutil test
> >  - Update comments
> >
> > Importantly, in order to make output consistent for both root and non-privileged
> > user, this changes the behavior of "subvolume list":
> >  - (default) Only list in subvolume under the specified path.
> >    Path needs to be a subvolume.
> >  - (-a) filter is dropped. i.e. its output is the same as the
> >         default behavior of "sub list" in progs <= 4.19
> >
> > Therefore, existent scripts may need to update to add -a option
> > (I believe nobody uses current -a option).
> > If anyone thinks this is not good, please let me know.
> 
> I think there are a few options in the case that the path isn't a
> subvolume:
> 
> 1. List all subvolumes in the filesystem with randomly mangled paths,
>    which is what we currently do.
> 2. Error out, which is what this version of the series does.
> 3. List all subvolumes under the containing subvolume, which is what the
>    previous version does.
> 4. List all subvolumes under the containing subvolume that are
>    underneath the given path.
> 
> Option 1 won't work well for unprivileged users. Option 2 (this series)
> is definitely going to break people's workflows/scripts. Option 3 is
> unintuitive. In my opinion, option 4 is the nicest, but it may also
> break scripts that expect all subvolumes to be printed.

I think my previous version is 4, or am I misunderstanding?
In previous version, output could be:
 $ mkfs.btrfs -f $DEV
 $ mount $DEV /mnt

 $ btrfs subvolume create /mnt/sub1
 $ btrfs subvolume create /mnt/sub1/sub2
 $ mkdir /mnt/sub1/dir
 $ btrfs subvolume create /mnt/sub1/dir/sub3

 $ btrfs subvolume list /mnt
  ID 256 gen 8 top level 5 path sub1
  ID 258 gen 7 top level 256 path sub1/sub2
  ID 259 gen 8 top level 256 path sub1/dir/sub3
 
 $ btrfs subvolume list /mnt/sub1
  ID 256 gen 8 top level 5 path .
  ID 258 gen 7 top level 256 path sub2
  ID 259 gen 8 top level 256 path dir/sub3

 $ btrfs subvolume list /mnt/sub1/dir
  ID 259 gen 8 top level 256 path sub3

https://lore.kernel.org/linux-btrfs/6af6dac8829d3ba405e3c53baffd828c9c428ef6.1529310485.git.misono.tomohiro@jp.fujitsu.com/

> 
> There's also an option 5, which is to keep the behavior the same for
> root (like what my previous patch [1] did) and implement option 4 for
> unprivileged users.
> 
> I think 4 and 5 are the two main choices: do we want to preserve
> backwards compatibility as carefully as possible (at the cost of
> consistency), or do we want to risk it and improve the interface?
> 
> 1:
> https://github.com/osandov/btrfs-progs/commit/fb61c21aeb998b12c1d0253263908
> 3d7f40c41e0