The subject says it all: if you try to run gparted as a non-root user,
gparted just puts up a message saying "you must be root".  Thing is,
I wanted to repartition an external device to which my non-root user
has read/write access.


	Stefan

Version: 0.3.3-2

That's the way gparted was disigned. Repartiotioning a disk drive may
have very serious consequences.

reopen 439409
thanks

What does it have to do with my request?
This non-root user can already cause the same serious consequences
without gparted (e.g. with a simple cat </dev/random >/dev/sdg).
More to the point, the fact that gparted refuses to do its job will just
force this user to either use lower-level tools that are even more
dangerous, or su to root, thus putting the whole system at risk since it
may then end up partitioning the wrong disk.

Tagging it as WONTFIX because we disagree might be OK, but I think
closing this bug is wrong because you did not address the problem.


        Stefan

Hi Stefan,

Are you sure that you can simply "cat </dev/random >/dev/sdg" on your
GNU/Linux distribution?


On my ubuntu 8.04 system, the underlying devices are not open to
unprivileged users, even if the user has access to the file system on
the mounted partition.

For example, the following command output was collected after inserting
my usb stick and having it automatically mounted on /media/USB-512MB:

$ df /media/USB-512MB
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sde1               496996    118872    378124  24% /media/USB-512MB
$ ls -ld /media/USB-512MB/
drwxr-xr-x 8 gedakc root 4096 1969-12-31 17:00 /media/USB-512MB/
$ ls -ld /dev/sde*
brw-rw---- 1 root disk 8, 64 2010-01-02 16:53 /dev/sde
brw-rw---- 1 root disk 8, 65 2010-01-02 16:53 /dev/sde1
$

As can be seen from the above commands, I can read and write to the file
system mounted at /media/USB-512MB (my userid is gedakc).

However, my userid would not be able to work on the underlying device
(/dev/sde in my case) without privileged access (root is the owner of
the /dev/sde device).

This is one of the main reasons why GParted requires root access to
manipulate partition tables on disk devices.

Regards,
Curtis Gedak

Sure, if that's the case, of course gparted can't work.
But you can certainly imagine a configuration where a non-root user
has full access to a device -- whether due to local site-specific
configuration or some standard thing like a device owned by group
floppy.  Or even consider an explicit "chmod 666 /dev/sdg" if the
sysadmin is feeling particularly generous.  Now clearly any user
can write to the device, so why in the world should "gparted" assume
that you need to be root and refuse to even try?

Yes, I'm sure "cat </dev/random >/dev/sdd" works for me.
So gparted should let me do my job rather than try outsmart Unix's permissions.
BTW, the symptom has slightly changed: now "gparted /dev/sdd" will complain
about "Inhibit all polling failed: Only uid 0 is authorized to inhibit the
daemon" (although "udisks --inhibit-polling /dev/sdd" seems to work), and if I
try and circumvent udisks by running "gpartedbin /dev/sdd" I now get a dialog
box which says the same as in my original bugreport tho with more words, and of
course it only offers "OK" (which here means "accept defeat") rather than also
offering an "I understand, but I still want to try".

Package: gparted
Version: 0.7.0-1
Severity: normal

% l /dev/sdd
brw-rw---- 1 root floppy 8, 48 21 jan 13:29 /dev/sdd
% id
uid=<NN>(monnier) gid=<NN>(monnier) groupes=..,<NN>(floppy),...
%

In the mean time, the symptom has changed slightly: now if I try to run
"gparted /dev/sdd" I'm told "Inhibit all polling failed: Only uid 0 is
authorized to inhibit the daemon".  Yet "udisks --inhibit-polling /dev/sdd"
seems to work OK, and even if it fails, it's no reason to deny me access to
gparted.
Then via `strace' I figured that I can run gpartedbin to circumvent the udisks
polling problem, at which point I see that rather than a mere "you must be
root", gparted now wastes his time giving me a big dialog box (saying the same
thing as before, tho with more words) to which I can only say "OK" which means
"accept defeat".
Please, please, pretty please, fix gparted so that it doesn't restrict access
more than `cat' does.

Normally (g)parted actually updates the kernel in memory partition table
to keep it in sync with the on disk partition table.  This requires root
access -- simply having write access to the block device is not enough.
I suppose you could allow a non root user to update the on disk
partition table, but then you will get told that updating the kernel
failed and you need to reboot for the changes to take effect.

severity 439409 important
thanks

Hi,

this report may is older. However I think thats a problem too. There a
scenarios I want to use partition tools without root. The first one is
the floppy-case as Stefan said. Another scenario is when I want to
create or partition an image which exists as file instead of an
physical disk. In this case there is no need to be root. Forcing the
user to switch to root for a task where it isn't needed is not only a
stupidly but also a serious security issue. This is why I set the issue
to "important"

Kind Regards,
Michael

The kernel requires root access to manipulate the in memory partition
table.  Simply having write permission to the block device is not
enough.  Therefore this is not and can not be a supported
configuration for (g)parted, so I am closing this bug.

reopen 439409
thanks

And of course, sometimes this fails even when you're root, and other
times the disk's partition hasn't been read by the kernel anyway.
IOW it's a nice feature but it doesn't justify preventing the user from
running gparted as non-root.
disk and replug it.


        Stefan

I have to concur with Stefan on this. My use case is even more
stupid -- no "real" device, but just a disk image as a file.

Fdisk "just works" on that, whereas gparted... see above.

With all this VM rage of late, this kind of use cases are expected
to proliferate. It doesn't help security if random programs force
the user to become root for no reason.

thanks
-- tomás

The usefulness of a gparted on an image file without being root is near
zero.  You can add or remove a partition, but can not see what
filesystems are currently in them, format a filesystem, check a
filesystem, or move a partition.  All of these things require a loopback
device with dev nodes for each partition, and that requires root.

If you are setting up a VM disk image, what good is it to be able to
create the partition, but not format a filesystem inside it?

unless root has set up fstab accordingly, to name but one variant.

This is a red herring. Hand-checking permissions in an application
is unnecessary and is a layering violation (OS should take care of
that, and it pretty well does). And... I can perfectly well
mkfs.ext4 as a regular user on a block device. It's just *mount*
which is special (and it's not the mount *application*, but the
mount *system call*: the layering is right here).

regards
-- t

fstab has nothing to do with it.  That only lets you mount and unmount
existing filesystems.

You don't *have* a block device on which to mkfs.  That's why you need
root and some sort of block device, like loop on which you can activate
a partition block device.

It sure has. The sysadmin can set up an fstab entry with the 'user'
option; she specifies a device (or an UUID, or a label) and a
mount point. The (regular) user can then mount, wihout any special
privileges.

Unless you know its offset whithin the containing block device, to which
you do have access (in the mentioned cases of an OS file viz. a device).
You don't need any loop device for that. You need he loop device for
*mounting* the file system, not for mkfs.

For activating (i.e. mounting), yes. Not for mkfs.

regards
-- tomás

That's what I just said.  This discussion isn't about mounting and
unmounting though, but rather is about partitioning.

Knowing the offset does not help since mkfs does not accept an offset
parameter; it expects the partition device.

sense), partitioning: doesn't need extra privileges (just an operation
on a bunch of bytes).

This is from the mkfs.ext2 man page:

  -E extended-options
    Set  extended  options  for  the  filesystem.  Extended options
    are comma separated, and may take an argument using the equals
    ('=') sign.  The -E option used to be -R in earlier versions of
    mke2fs.  The -R option is still accepted for backwards compatibility,
    but is deprecated.  The following extended options are supported:

       [...]
       offset=offset
         Create the filesystem at an offset from the beginning of the
         device or file.  This can be useful when creating disk images
         for virtual machines.

regards
-- t

ext isn't the only filesystem.

We're losing sight of the bug's topic, which is whether gparted should
check for itself on the invoking user's ID or not.

I'm convinced it shouldn't and tried to explain my point. I think I can't
do better. Phil and me are getting lost in a useless discussion.

I think I should just stop here.

Regards & bye
-- tomás