> -----Original Message----- > From: Omar Sandoval [mailto:osandov@xxxxxxxxxxx] > Sent: Friday, December 7, 2018 10:02 AM > To: Misono, Tomohiro/味曽野 智礼 <misono.tomohiro@xxxxxxxxxxx> > Cc: linux-btrfs@xxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxx/ > > 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
