On 01/26/2013 03:18 AM, Russell Coker wrote:
On Sat, 26 Jan 2013, Gene Czarcinski<gene@xxxxxxxxx> wrote:OK, I think I have gotten the message that this is a bad idea as implemented and that it should be dropped as such. I believe that there are some things ("btrfs fi show" comes to mind) which will need root and I am going to explore doing something for that case. And it also might be reasonable for some situations to issue the message about root if something errors-out.I think that a message such as Eric proposed of "failed to open /dev/sda: Permission denied" is clear enough. If you run as non-root on a system with no security system other than Unix permissions then it will be quite obvious that such an error can be fixed by running as root.
Being pedantic, I would point out that the kernel is checking if the user has CAP_SYS_ADMIN, which could be different than geteuid() == 0. I can have both a root users without CAP_SYS_ADMIN and a normal user with this capability.
If I can make a suggestion, the work of Gene could be changed in checking which command really requires to be root.
To day I can create a subvolume, and remove a subvolume [1] without needing root. I am guessing if there is a valid reason to require "root" to list the subvolumes.
I know that behind the command "find-subvolumes" there is the ioctl BTRFS_IOC_TREE_SEARCH which requires to be root, because it could export some sensible information. But this can be easy solved creating an ioctl which export only not-sensible data (i.e. it export only the name and the path of the subvolume).
I think that a good analysis of these situations could improve the btrfs usability.
My 2¢ BR G.Baroncelli
But if you are running SE Linux or some other security system then you could be prevented from running the program without the root/non-root status of it being relevant.
[1] Passing user_subvol_rm_allowed in option -- 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
