linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Goffredo Baroncelli <kreijack@gmail.com>
To: russell@coker.com.au
Cc: Gene Czarcinski <gene@czarc.net>,
	linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH] Btrfs-progs: Exit if not running as root
Date: Sat, 26 Jan 2013 08:46:43 +0100	[thread overview]
Message-ID: <510389E3.1070002@gmail.com> (raw)
In-Reply-To: <201301261318.59880.russell@coker.com.au>

On 01/26/2013 03:18 AM, Russell Coker wrote:
> On Sat, 26 Jan 2013, Gene Czarcinski<gene@czarc.net>  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

  reply	other threads:[~2013-01-26  7:46 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-25 11:32 [PATCH] Btrfs-progs: Exit if not running as root Gene Czarcinski
2013-01-25 11:41 ` Stefan Behrens
2013-01-25 12:03   ` Gene Czarcinski
2013-01-25 12:17     ` Stefan Behrens
2013-01-25 13:22       ` Gene Czarcinski
2013-01-25 11:55 ` Roman Mamedov
2013-01-25 12:29   ` Gene Czarcinski
2013-01-25 12:43     ` Hugo Mills
2013-01-25 15:19       ` Brendan Hide
2013-01-25 13:00     ` Roman Mamedov
2013-01-25 13:52   ` Russell Coker
2013-01-25 15:04 ` Gene Czarcinski
2013-01-25 15:10   ` Gene Czarcinski
2013-01-25 15:30   ` cwillu
2013-01-25 16:06   ` Eric Sandeen
2013-01-26  2:18   ` Russell Coker
2013-01-26  7:46     ` Goffredo Baroncelli [this message]
2013-01-25 15:07 ` Eric Sandeen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=510389E3.1070002@gmail.com \
    --to=kreijack@gmail.com \
    --cc=gene@czarc.net \
    --cc=kreijack@inwind.it \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=russell@coker.com.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).