gksuexec doesn't work in dapper !

Bug #47388 reported by Christophe Charlot on 2006-05-29
Affects Status Importance Assigned to Milestone
gksu (Ubuntu)

Bug Description

Binary package hint: gksu

Each time I try tu use 'Start as another user' (sorry, maybe the translation from french isn't exact), it doesn't work.

Example :
If I am 'userA' and I want to start gaim as 'userB' , I have a password error if I use 'userB' password. If I use root password, there is no error message, but gaim won't start. (gaim is just an example, it is the same behaviour for all applications).

If I try from terminal, with 'userB' password, here is the output :
christophe@christophe:~$ gksuexec
sudo: 1 incorrect password attempt

This is if I use the 'userB' password

If I use root password :
christophe@christophe:~$ gksuexec
Gaim 2.0.0beta3
Xlib: No protocol specified

(gaim:15535): Gdk-CRITICAL **: gdk_display_get_name: assertion `GDK_IS_DISPLAY (display)' failed

** (gaim:15535): WARNING **: cannot open display: unset

I remember I had the same problem when I upgraded from hoary to breezy, and now it happens again upgrading from breezy to dapper....

Christophe Charlot (c-charlot) wrote :

Forgot to tell : this bug is happening after upgrading from breezy to dapper yesterday... I'm not sure it happens with a fresh clean install...

Sebastian Heinlein (glatzor) wrote :

We use the sudo mode by default. You have to allow your user to execute commands of the other user using visudo.

Or switch from sudo to su mode using gconf: /apps/gksu/sudo-mode.

Perhaps this should be written down in the documentation.

The other problem is that you don't get a response if sudo fails which is the case here.

So I don't know how to handle this bug. It seems to be a feature and not a bug :)



Changed in gksu:
assignee: nobody → glatzor
status: Unconfirmed → Confirmed
Sebastian Heinlein (glatzor) wrote :

Sorry. My reply is wrong. There seems to be another issue with using other users than root.

Christophe Charlot (c-charlot) wrote :

It seems that with the new kernel (2.6.15-25-686 ) this problem is now solved.... (maybe another package was released with the kernel) ?

Christophe Charlot (c-charlot) wrote :

... not completely solved in fact.. ;-)

I cant launch another program as another user, but I need to use the root password, not the other user's password.

Strange behaviour !!

Christophe Charlot (c-charlot) wrote :

New comment regarding the last one... and it's getting even more strange.

This behaviour is happening only when i'm using XGL/compiz, when I start a 'normal' Gnome session, I'm still at case one : gksuexec isn't working : no way to launch a program as another user (other than root)...

Changed in gksu:
assignee: glatzor → nobody
Michael Vogt (mvo) wrote :

Thanks for this additional information. I just tried to reproduce it and was not able to.

To reproduced I ran "gksuexec" and selected userB and the "id" command. The passwort dialog came up asking me for my password and after that "id" showed the output for userB.

Do you have a explicit root password set? Instead of using your passwort and do everything through sudo (which is the default)?


Changed in gksu:
status: Confirmed → Needs Info
Christophe Charlot (c-charlot) wrote :

Thanks for taking care of this bug which is annoying me so much ;-)

I'll try to sum-up everything I can tell you about this bug so far :

- I DO NOT have an explicit root password, I always use sudo from my main account (userA), which is the only sudoer in the system.

- This bug happened after an upgrade from breezy, and I had almost the same problem when upgrading from hoary to breezy. The problem disappeared when I made a fresh clean install of breezy.
- I do not know if this bug appears with a clean install of Dapper.

- In a standard Gnome session as userA, if I try to launch "id" as "userB" in a terminal : gksuexec -> id and choose userB
 - if I use userB password it's not working :
   sudo: 1 incorrect password attempt"
 - if I use userA password it's working !! :
   "uid=1001(userB) gid=1001(userB) groupes=4(adm),20(dialout),21(fax),24(cdrom),25(floppy),26(tape),29(audio),30(dip),44(video),46(plugdev),104(lpadmin),105(scanner),1001(userB)"

- BUT in a standard Gnome session with userA, if I try to launch "firefox"(or any 'graphical' program) as "userB" :
 - still not working with userB password.
 - with userA password now it's not working :
  "Xlib: connection to ":0.0" refused by server
  Xlib: No protocol specified
  (firefox-bin:2436): Gtk-WARNING **: cannot open display:"

- Now I start a standard Gnome session as "userB" and start "id" as "userA" :
 - with "userA" password it's not working :
   sudo: 1 incorrect password attempt"
 - with "userB" password : I get a message that "userB" is not a sudoer and cannot do this, error will be reported...

- Now I start an XGL/Compiz session :

 - userA gksuexec 'id' & 'userB' -> working WITHOUT being asked for a password !!!!!
 - userA gksuexec 'firefox' & 'userB' -> same result !!!

 - If I launch gksuexec from the drop-down menu (start as another user), I'm asked for the password, and I get the same results than in a standard gnome session, except that I CAN start 'graphicals' programs.

I do not understand much what is happening, but the only thing I am sure of, is that it's not working as it should ;-)

I hope everything in here will help you. I can do any other test if you want, no problem :-)

Christophe Charlot (c-charlot) wrote :

Ok, I made some more tests, this time on a 'clean' install of dapper (as a guest OS with mware server).
userA is the first account and is sudoer.
userB is the second account and is NOT sudoer.

Login with userA : gksuexec -> id as userB and using userB password :
  sudo : 1 incorrect password attempt.

Login with userA : gksuexec -> id as userB and using userA (root) password :
  uid=1001(userB).... it's working

Login with userA : gksuexec -> firefox as userB :
  Xlib : connection to ":0.0" refused by server
  Xlib: No protocol specified

(firefox-bin:7828): Gtk-WARNING **: cannot open display

I'm sure there is a bug somewhere... will test on edgy in the hope I can install knot2 as a vmware guest ;-)

Christophe Charlot (c-charlot) wrote :

Ok , tried to test it on edgy eft knot 2... gksuexec is't there anymore :-(((

Jussi Kukkonen (jku) wrote :

As far as I understand gksuexec should accept only userA password, exactly like sudo... Using userB password should not work.

So when you're logged in as UserA, you gksudoexec with userA password and select userB. You need to have permissions for this of course... This seems to work as expected, correct?

the Xlib error could be a bug, not sure about that.

Christophe Charlot (c-charlot) wrote :

That's not the way it used to work in Hoary and Breezy : if you wanted to start a program as userB you had to enter userB password.

Note that when you are asked for a password it is written (translating) :
Please enter your password to start "application X" as userB.

This bug has no assignee - just wondering if it's dropped off the radar, as it still affects gutsy.

I'm affected by this bug too (though it's now gksu, no gksuexec) - let me know if there's anything I can do to help debug things.

Launchpad Janitor (janitor) wrote :

[Expired for gksu (Ubuntu) because there has been no activity for 60 days.]

wam (anthonymahe) wrote :

There is a difference between gksudo (graphical equivalent to sudo) and gksu which will prompt for the password of the so called "root" user (not superuser).

If an application uses gksu by mistake, you'll need to create a root user, assign a password (sudo passwd root) and use that password of the root user.

I'm not actually running anything from an application. My use case is that I have two accounts (one for work, one for personal use). Occasionally, I'm in one session and want to run a program as my other account.

It seems that the -u option neither works in gksu, or gksudo.

I'm now running Hardy beta. Running gksudo with -u resulted in the following output after asking me for my password:

darrenw@washington:~$ gksu -u warnerd thunderbird

(thunderbird-bin:10508): Gtk-WARNING **: cannot open display: :0.0

Then running gksudo came straight back to the command prompt (though it looks like an application window popped up for an instant). Running gksu again results in the same behaviour. Running gksu or gksudo without -u works Ok.

Changed in gksu:
status: Invalid → New
wam (anthonymahe) wrote :

sorry for this, I realise my response has absolutely nothing to do with your problem, I must have written in the wrong tab...

sorry for this

Does this still happen in the final version of hardy? And if so could you also try in the latest alpha of intrepid?

Still the same result in hardy final. I'll install intrepid in a VM and let you know what happens.

Just tried intrepid (beta 1, updated as of 2008/10/08) - same result :)

I must have been happy inside. Should have said :( though.

Daniel T Chen (crimsun) wrote :

I can't confirm this symptom in 9.04. Please set the status to:
1) New if reproducible in a supported or development Ubuntu version, or
2) Invalid if you cannot reproduce it in a supported or development Ubuntu version.

Changed in gksu:
status: New → Incomplete

Still there in 8.10 (I don't have 9.04, and am a little reluctant to install it yet given that the status of this bug hasn't changed since dapper - unless you think something has changed that might help, or there's something I can try?)

(I entered the wrong password on the first attempt, but I've pasted the entire output to show what happens after the password has been cached):

warnerd@washington:~$ gksu -u darrenw thunderbird
sudo: 1 incorrect password attempt
(thunderbird-bin:452): Gtk-WARNING **: cannot open display: :0.0
warnerd@washington:~$ gksu -u darrenw thunderbird
No protocol specified
(thunderbird-bin:477): Gtk-WARNING **: cannot open display: :0.0

Changed in gksu:
status: Incomplete → New

I can confirm this bug in Ubuntu 9.04 (my first steps with Gnome after several years of KDE).

======= works =============
eduard@nb-ewulff:~$ gksudo -d nautilus

No ask_pass set, using default!
xauth: /tmp/libgksu-u3Ectl/.Xauthority
STARTUP_ID: gksudo/nautilus/16567-0-nb-ewulff_TIME10844278
cmd[0]: /usr/bin/sudo
cmd[1]: -H
cmd[2]: -S
cmd[3]: -p
cmd[5]: -u
cmd[6]: root
cmd[7]: --
cmd[8]: nautilus
buffer: --
brute force GNOME_SUDO_PASS ended...
No password prompt found; we'll assume we don't need a password.
xauth: /tmp/libgksu-u3Ectl/.Xauthority
xauth_env: /home/eduard/.Xauthority
dir: /tmp/libgksu-u3Ectl

======= does not =============
eduard@nb-ewulff:~$ gksudo -d -u palo nautilus

No ask_pass set, using default!
xauth: /tmp/libgksu-tYOcES/.Xauthority
STARTUP_ID: gksudo/nautilus/16570-0-nb-ewulff_TIME10864983
cmd[0]: /usr/bin/sudo
cmd[1]: -H
cmd[2]: -S
cmd[3]: -p
cmd[5]: -u
cmd[6]: palo
cmd[7]: --
cmd[8]: nautilus
buffer: -No protocol specified-
brute force GNOME_SUDO_PASS ended...
No password prompt found; we'll assume we don't need a password.
No protocol specifiedCould not parse arguments: Anzeige kann nicht geöffnet werden:
xauth: /tmp/libgksu-tYOcES/.Xauthority
xauth_env: /home/eduard/.Xauthority
dir: /tmp/libgksu-tYOcES

The last case is what I want. I can login as user palo but switching between whole sessions is not my intention.

Still there in Karmic:

warnerd@washington:~$ lsb_release -c
Codename: karmic
warnerd@washington:~$ gksu -u darrenw firefox
No protocol specifiedNo protocol specified
Error: cannot open display: :0.0

Anders Østerholt (diebels) wrote :

$ xhost +LOCAL:
non-network local connections being added to access control list

Now you can gksu -u anotheruser program

You can add this command to your startup programs in gnome-session-properties.

As for using the other users password for authentication is not correct behaviour. When you sudo, you use your own password.

You may also use fast user switcher to run programs as another user.

This bug is not valid.

Changed in gksu (Ubuntu):
status: New → Invalid

Many thanks Anders - I can now finally use gksu again!

However, while I think I understand the technical reasons for the way things are, from a more holistic perspective I disagree that this bug should be marked invalid for the following reasons:

- It requires _more_ steps to run programs as another user compared with running programs as root (this just seems wrong)
- I don't think people running GNOME should need to be concerned about the details of X security ("GNOME is not UNIX" argument)
- gksu fails to run as documented with no discernible reason why (at the very least, a note with the above solution should be added to man pages/documentation)

I don't enter the other users password when running the program as that user - gksu asks me for my own password (in the same way that it asks me for my own password when running a program as root)

I'm aware of the fast user switcher, but gksu serves a different (and often more convenient) purpose. One could argue the same for running anything else as root.


To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers