Gparted won't accept root password??? [SOLVED!]

[Bald Brick]

You asked .......  yes it seems to be a common problem ..... at least it is reproducible here

gksu gparted     tells me my password is invalid
su -c "gparted"  tells me my password is invalid
su -c gparted     tells me my password is invalid

opening a terminal,  'su'-ing to root, then launching gparted works.

kdesu gparted   accepts the root password and launches

Here "gksu gparted" doesn't work either, but "gksu -l gparted" does. The "-l" is a lower case "L", and the option makes "gksu" start a login shell (like "su -l" or just "su -").

(Incidentally, "su" and "su -" have become a bit unreliable. In some installations "su -" is an alias for "su", and in some it's not. This means that in some cases "su" may need a slightly different syntax than we're accustomed to.)

[djohnston]

OK, this is a bit weird. Fully updated, current Zen Mini installation. As you can see, the desktop file uses the "gksu -l gparted" command string. It works correctly if I launch GParted from the menu file More Applications>Configuration>GParted. However, if I use that command string within a terminal, I get an incorrect password error response.

Code: [Select]

[darrel@localhost ~]$ cat /usr/share/applications/gparted.desktop
[Desktop Entry]
Encoding=UTF-8
Name=GParted
GenericName=Partition Editor
_X-GNOME-FullName=GParted Partition Editor
Comment=Create, reorganize, and delete partitions
Exec=gksu -l gparted
Icon=gparted
Terminal=false
Type=Application
Categories=GNOME;System;Settings;Filesystem;X-MandrivaLinux-System-Configuration-Hardware
StartupNotify=true
[darrel@localhost ~]$
Looking for gparted executable, I see there's one in /usr/bin and another one in /usr/sbin.

Code: [Select]

[darrel@localhost ~]$ ls -l /usr/sbin/gparted
-rwxr-xr-x 1 root root 2519 Feb 17  2011 /usr/sbin/gparted*
[darrel@localhost ~]$ ls -l /usr/bin/gparted
lrwxrwxrwx 1 root root 13 Jul 19  2011 /usr/bin/gparted -> consolehelper*
[darrel@localhost ~]$
The odd thing is the the one in /usr/bin is soft linked to consolehelper. And, according to the (stock unaltered) system search path, /usr/bin is searched, but /usr/sbin is not.

[darrel@localhost ~]$ echo $PATH
/bin:/usr/bin:/usr/local/bin:/usr/games:/usr/lib/qt4/bin:/home/darrel/bin
[darrel@localhost ~]$

If I enter "gparted" command string in a terminal, an error message comes up immediately saying the supplied password is incorrect, even though no password was requested or supplied. If, however, I enter "gksu -l /usr/sbin/gparted" command string in a terminal, the password requester comes up, and gparted launches after supplying root's password.

1. /usr/bin/gparted points to consolehelper.
2. /usr/sbin is not included in (my) user's search path, but probably should be.
3. The "gksu -l gparted" command string within the desktop file works here when GParted is launched from the menu, but the command string fails from the terminal. (It calls "gksu -l /usr/bin/gparted from my searchpath.) (Why does the desktop file work?)
4. The "gksu -l /usr/sbin/gparted" command string in a terminal works correctly.

[Neal ManBear]

Did you try launching with just gparted?     
Also try gksu -d gparted. This will return debugging info.     

The link to consolehelper might be explained by ---     
gksu -l = Make this a login shell. Beware this may cause
problems with the Xauthority magic. Run xhost
to allow the target user to open windows on your
display!     

[djohnston]

Did you try launching with just gparted?    
Also try gksu -d gparted. This will return debugging info.    

If I enter "gparted" command string in a terminal, an error message comes up immediately saying the supplied password is incorrect, even though no password was requested or supplied.

I'll get back to you in a minute on the other.

EDIT: Okay, here's the output:

[darrel@localhost ~]$ gksu -d gparted
xauth: -23b89a0a1c67784696e22e58ead7ec27
-
display: -:0.0-
final xauth: -23b89a0a1c67784696e22e58ead7ec27
-
final display: -:0.0-
STARTUP_ID: gksu/gparted/2378-0-localhost.localdomain_TIME0
gksu_context_run: buf: -Password: -
no password on keyring
DEBUG (run:after-pass) buf: -Password: -
-EBUG (run:post-after-pass) buf: -
-EBUG (run:post-after-pass) buf: -gksu: waiting
-EBUG (gksu: waiting) buf: -gksu: waiting
[darrel@localhost ~]$

[Neal ManBear]

By "gparted command string," I thought you meant "gksu -l gparted." To me a command string is a command plus options and/or arguments.     

[djohnston]

Well, the forum quit responding. Here's the rest:

Run xhost to allow the target user to open windows on your display!     

I'm not sure what you're getting at. Both user darrel and user root can open windows on the display.

[pags]

Bear in mind that root's PATH will not be the same as the user's PATH.

About consolehelper:

Code: [Select]

CONSOLEHELPER(8)                                                              CONSOLEHELPER(8)

NAME
       consolehelper - A wrapper that helps console users run system programs

SYNOPSIS
       progname [ options ]

DESCRIPTION
       consolehelper  is  a  tool that makes it easy for console users to run system programs,
       doing authentication via PAM (which can be set up to trust all console users or to  ask
       for a password at the system administrator's discretion).  When possible, the authenti‐
       cation is done graphically; otherwise, it is done within the text  console  from  which
       consolehelper was started.

       It  is  intended to be completely transparent.  This means that the user will never run
       the consolehelper program directly.  Instead, programs like /sbin/shutdown  are  paired
       with a link from /usr/bin/shutdown to /usr/bin/consolehelper.  Then when non-root users
       (specifically, users without /sbin in their path, or /sbin  after  /usr/bin)  call  the
       "shutdown"  program,  consolehelper will be invoked to authenticate the action and then
       invoke /sbin/shutdown.  (consolehelper itself has no priviledges; it  calls  the  user‐
       helper(8) program do the real work.)

       consolehelper requires that a PAM configuration for every managed program exist.  So to
       make /sbin/foo or /usr/sbin/foo managed, you need to create a link from /usr/bin/foo to
       /usr/bin/consolehelper  and create the file /etc/pam.d/foo, normally using the pam_con‐
       sole(8) PAM module.

OPTIONS
       This program has no command line options of its own; it passes all command line options
       on to the program it is calling.

SEE ALSO
       userhelper(8)

AUTHOR
       Michael K. Johnson <johnsonm@redhat.com>

Red Hat Software                         18 March 1999                        CONSOLEHELPER(8)

So, if consolehelper is not a problem, the existence of the link seems fine...

[wharfhouse]

And I thought that was the end of it!  This is getting more interesting by the minute...

consider the thread re-opened and I'll keep a watching brief on all this technical stuff!

 

[Neal ManBear]

Well, the forum quit responding. Here's the rest:

Run xhost to allow the target user to open windows on your display!     

I'm not sure what you're getting at. Both user darrel and user root can open windows on the display.

     
I quoted an entire paragraph from the help file. The salient bit is in italics.     

The link to consolehelper might be explained by ---     
gksu -l = Make this a login shell. Beware this may cause
problems with the Xauthority magic. Run xhost
to allow the target user to open windows on your
display!

     
In other words, it could be the use of the -l option that is causing a problem. Perhaps a switch from -l to -u root would work.     

[djohnston]

Bear in mind that root's PATH will not be the same as the user's PATH.

Yes, that's true. The examples shown were all started as a normal user. Let me see if I can make things a bit clearer. If I call /usr/bin/gparted implicitly as a normal user, I immediately get an error message that the requested password was invalid, even though no password was requested or entered.



If I call /usr/sbin/gparted implicitly as a normal user, I get an error message that the program must be run as root.



If I issue the command gksu -l /usr/sbin/gparted as a normal user, root's password is requested, and the gparted program starts.



As far as /usr/bin/gparted versus /usr/sbin/gparted, it's the same situation. If I implicitly call /usr/bin/gparted as root, I still get the invalid password error.



If I implicitly call /usr/sbin/gparted as root, the gparted program starts.

[Neal ManBear]

djohnston,     
Try as user gksu -u root gparted. This tells gksu to launch gparted as user root but does not call for the login shell as gksu -l gparted does.     

[djohnston]

djohnston,    
Try as user gksu -u root gparted. This tells gksu to launch gparted as user root but does not call for the login shell as gksu -l gparted does.    

Well, "gksu -u root gparted" brings up the password requester. After entering root's password, I still get the "invalid password" error. Adding the debug switch by entering "gksu -d -u root gparted", I get the following terminal output after the password is requested and fails.

[darrel@localhost ~]$ gksu -d -u root gparted
xauth: -03a348c95eb2318504be2c16bd852145
-
display: -:0.0-
final xauth: -03a348c95eb2318504be2c16bd852145
-
final display: -:0.0-
STARTUP_ID: gksu/gparted/2444-0-localhost.localdomain_TIME0
gksu_context_run: buf: -Password: -
no password on keyring
DEBUG (run:after-pass) buf: -Password: -
-EBUG (run:post-after-pass) buf: -
-EBUG (run:post-after-pass) buf: -gksu: waiting
-EBUG (gksu: waiting) buf: -gksu: waiting
[darrel@localhost ~]$


EDIT: I should note here that this has never been a problem for me, as I don't particularly like GParted. I'm just attempting to do some debugging.

[Neal ManBear]

I'm just attempting to do some debugging.

     
Me, too.     

[djohnston]

Looking back at pags's post on consolehelper, I see

"consolehelper requires that a PAM configuration for every managed program exist.  So to make /sbin/foo or /usr/sbin/foo managed, you need to create a link from /usr/bin/foo to /usr/bin/consolehelper  and create the file /etc/pam.d/foo, normally using the pam_con‐sole( PAM module."

Well, just checked /etc/pam.d directory, and there is a gparted file. The contents are:

USER=root
PROGRAM=/usr/sbin/gparted
SESSION=true

[Neal ManBear]

That seems correct to me.     

Here these commands launch gparted without issue:     
gksu -l /usr/sbin/gparted     
gksu -u root /usr/sbin/gparted     

As root (su):     
usr/sbin/gparted
-bash: usr/sbin/gparted: No such file or directory