GNOME Bugzilla – Bug 381557
ask root password when gparted is run as normal user
Last modified: 2013-05-02 18:34:51 UTC
since gparted comes with a .desktop file for desktop menus, i think you should be able to start gparted as a normal user and then be asked for the root password to unlock its abilities else the .desktop file is totally useless unless you use your desktop as root, which you shouldn't do, of course. * run gparted * [enter root password] [quit gparted] something like that.
but isn't this a distros responsibility? I know ubuntu and FC do it. And if not, what would be the correct way of implementing this?
Desktop icon now prompts for root password. This code has been committed in the new SourceForge repository. (http://gparted.sourceforge.net/svn.php) gksu command added in front of gparted execution in the .desktop file. See also bug http://bugzilla.gnome.org/show_bug.cgi?id=440012
maybe this should be done with to policykit in the future, but thanks anyway for now :)
Rolled HIG code changes (bug 440012) back to 0.3.3, and hence re-opened this bug. I encountered difficulties with international language translation after making the suggested changes for bug #440012. This bug was included in the changes for bug #440012. Not wishing to hold up a new release (0.3.5) of gparted, I have backed out the changes. I will review these changes later when I have a better understanding of international language translation. Sincerely, Curtis Gedak
More to the point, why even bother asking for root? Some devices you can modify as a normal user (for example, virtual disks) or if you set up your permissions right (for example, removable hard disks) you never have to become root... Why not deal with permission problems later? (when I wanted to use gparted on my virtual disks -- I couldn't without becoming root.. I also often set up disks so I can read them (but not write them). Also, I'm running 0.3.3 -- how do I see the version WITHOUT becoming root ;-) I made this simple change for now: : leisner@gateway 01:03:38;rcsdiff -u src/main.cc =================================================================== RCS file: src/main.cc,v retrieving revision 1.1 diff -u -r1.1 src/main.cc --- src/main.cc 2008/02/05 05:29:35 1.1 +++ src/main.cc 2008/02/05 05:30:54 @@ -35,7 +35,7 @@ //check UID if ( getuid() != 0 ) { - Gtk::MessageDialog dialog( _("Root privileges are required for r unning GParted"), + Gtk::MessageDialog dialog( _("Root privileges may be required fo r running GParted"), false, Gtk::MESSAGE_ERROR, Gtk::BUTTONS_OK ) ; @@ -43,7 +43,6 @@ _("Since GParted can be a weapon of mass destruc tion only root may run it.") ) ; dialog .run() ; - exit( 0 ) ; } //deal with arguments..
Hi Marty, Thank you for your input. You have presented some good points about not always needing root access. I will consider these in future changes. In the meantime, I still have a lot of learning ahead of me to become comfortable with the GParted source code. Currently I do not know all the implications of making such a change at this time. Regards, Curtis
Perhaps just add an option to inhibit the root check? Its always a better idea to run a program on the least permissions possible. If you try to execute one of the commands, and they fail, so be it. When I tried to run it, I got core dumps... Its also a VERY difficult problem to debug root processes (debugging as user on virtual disk images makes things much simpler and safer). marty
Thanks again, Björn, for the report of this problem. The desktop icon once again prompts for the root password. The gksu command was added in front of gparted execution in the .desktop file. This change has been committed to the gparted gnome repository for inclusion in the next release. Response to comment #5: Thank you for your input Marty. After more review of the code, I have decided to maintain the requirement that gparted be run by root. It is a non-trivial exercise to change gparted to only prompt for root when it requires elevated access. Regards, Curtis Gedak
Re-opening this bug (yes again :-). gksu is not supported across all major GNU/Linux distributions (e.g., Fedora) as pointed out in bug #529622. As Björn pointed out in comment #3, PolicyKit should provide a better solution. From a quick google search, it would appear that PolicyKit usage is a fairly recent addition to GNU/Linux distributions: Ubuntu - will introduce PolicyKit in Hardy Heron (v8.04) Fedora - introduced PolicyKit in Fedora 8 SUSE - introduced in 10.2 Debian - will introduce PolicyKit in Lenny
As I do not have a firm grasp of how to solve this problem using PolicyKit, I have implemented an interim enhancement. A check has been added to the configure process to determine if the gksu program is available. In this way GNU/Linux distributions that use gksu can benefit from being able to invoke gparted from the menu and prompt for the root password. At the same time, distributions without gksu are not adversely affected. Any assistance with how to solve this bug using PolicyKit would be much appreciated.
Deassigning this bug because I am not actively working on it.
The Ubuntu package has a patch to make gparted use pkexec. Maybe you could include that?
Phillip, is pkexec used by other distributions, such as Fedora, Debian, or SUSE? The ideal goal would be to not request root access until it is needed by GParted. This is a non-trivial task to change GParted to work this way. In fact just scanning all the drives requires root access, so this would only be useful for perhaps plug-in user-access USB drives. A desirable middle ground would be to use a mechanism available on all GNU/Linux distributions to acquire root privilege when GParted is invoked. Currently the GParted desktop icon will configure to use "gksu" if it is available.
You said back in 2008 that Ubuntu, Fedora, SUSE, and Debian were moving to PolicyKit. Not requesting root until it is needed would require a near complete rewrite of gparted to separate it into a gui frontend app and a separate backend to actually manipulate the disk.
My apologies Phillip. I did not realize that pkexec was part of PolicyKit. If that is the case then this might indeed be a good solution to this problem. It might be a while before I get a chance to test this on the various distributions. There is lots of active development on GParted and I need to review several in-progress bug developments.
*** Bug 693275 has been marked as a duplicate of this bug. ***
I think this bug is long overdue for closing as it was fixed by including gksu in the .desktop file.
Since the problem originally reported has been fixed by adding gksu (if available) to the .desktop file, I agree that this report should be closed. Marking this reported as RESOLVED.