On 03/22/2018 01:15 PM, Austin S. Hemmelgarn wrote: > On 2018-03-21 16:38, Goffredo Baroncelli wrote: >> On 03/21/2018 12:47 PM, Austin S. Hemmelgarn wrote: >>> I agree as well, with the addendum that I'd love to see a new ioctl that >>> does proper permissions checks. While letting rmdir(2) work for an empty >>> subvolume with the appropriate permissions would be great (it will let rm >>> -r work correctly), it doesn't address the usefulness of being able to just >>> `btrfs subvolume delete` and not have to wait for the command to finish >>> before you can reuse the name. >> >> How this could work ? >> >> If you want to check all the subvolumes files permissions, this will require >> some time: you need to traverse all the subvolume-filesystem; and only if >> all the checks are passed, you can delete the subvolume. >> >> Unfortunately I think that only two options exist: >> - don't check permissions, and you can quick remove a subvolume >> - check all the permissions, i.e. check all the files permissions, and only >> if all the permissions are OK, you can delete the subvolume. However this >> cannot be a "quick" subvolume delete > > Why exactly would you need to check everything? What I'm talking about is > having behavior like `user_subvol_rm_allowed` be the default, with an > additional check emulating the regular dentry removal check (namely that the > user has appropriate permissions on the parent directory) so that people > can't delete things like their own home directories. We're already _way_ > beyond POSIX semantics here because we're debating the handling of > permissions for an ioctl that takes a different fd than what it functionally > operates on, so I see no reason whatsoever that we need to enforce POSIX > semantics to that degree. >
Why "user_subvol_rm_allowed" doesn't satisfy your needing ? Does not perform enough permission checking ? BR G.Baroncelli -- gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it> Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 -- 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
