sudo *something which uses policykit?* doesn't work

Bug #210897 reported by emil.s on 2008-04-02
This bug affects 3 people
Affects Status Importance Assigned to Milestone
consolekit (Ubuntu)
Nominated for Hardy by Julien Huang
Nominated for Intrepid by Julien Huang
Nominated for Jaunty by Julien Huang
sudo (Ubuntu)
Nominated for Hardy by Julien Huang
Nominated for Intrepid by Julien Huang
Nominated for Jaunty by Julien Huang

Bug Description

Binary package hint: policykit

I have added myself to the "sudo" group, and removed myself from the "admin" group for being able to use sudo without needing to fill in my password...
Every CLI applications works, but not the GUIs which is using policykit (those with the "Unlock" button)

If I start for example the "network-admin" program and press "Unlock", the program freezes a minute and then displays an error message.
And if I start something as root (sudo network-admin), I doesn't have the "Unlock" button at all. And I can't change anything either. As root, I should ;-)

I'm using Hardy, updated 5 minutes ago.

This is particularly a problem for users upgrading from previous versions of Ubuntu, as several menu items (e.g., network) have "gksu" in the command line, and the menu entries are not properly reverted during upgrade. It took me a while to figure out that I had to revert (or manually remove the "gksu") from many "administration" menu items in order to actually do anything, since root is apparently locked out of policykit.

Dovel (dov01) wrote :

I can authenticate this bug. I did a fresh install, but kept my old home folder (on a separate partition). Some of the menu items (network-admin) were upgraded, while users-admin and shares-admin were NOT upgraded and I had to remove the gksu manually. Strange that I had the problem anyway, I thought I'd deleted all the gnome config files...

I think the bug should be given some importance, as a lot of people would keep their home folder on a separate partition and just mount it in during installation of Hardy.


When I run gdmflexiserver from gnome-terminal on Solaris, it fails and shows me error.

"Unable to determine session: Unable to lookup information about calling process 110051"

Root cause is envrionment variable "XDG_SESSION_COOKIE" of my bash process is lost due to using custom ~/.bashrc. That results in ConsoleKit unable to return correct session id from "org.freedesktop.ConsoleKit.Manager.GetCurrentSession"

Created an attachment (id=16426)
A possible fix

Check"XDG_SESSION_COOKIE" in not only current process but also its parent process .


I an reproduce this issue here. I believe there was a fix uploaded that
intended to make it possible to be root and use these applications, it
doesn't seem to have been enough.

emil.s, if you add yourself back to the "admin" group, are you able to
use the apps without sudo?



Changed in policykit:
importance: Undecided → Medium
status: New → Confirmed

This error is related to sudo not keeping XDG_SESSION_COOKIE env variable

Add the following to /etc/sudoers
Defaults env_keep += "XDG_SESSION_COOKIE"

I tried to corrected the sudo package but the sudoers file is created by scripts.


James Westby (james-w) wrote :


I've reassigned this to consolekit, as that is the process that relies on
XDG_SESSION_COOKIE being available.




Do you have a comment on this issue and the proposed patch? It would
seem as though this would also allow policykit-using tools to work
under sudo, which there have been bug reports about in Ubuntu, e.g.



Changed in consolekit:
status: Unknown → Confirmed
Martin Pitt (pitti) on 2008-10-02
Changed in sudo:
status: New → Invalid

Check with the Ubuntu bug, it guess it is similar with the following case in Solaris:
$su -
<input your root password>
#env|grep XDG

If we use "su" instead of "su -" in upper case, the XDG_SESSION_COOKIE is retained. So gdmflexiserver can start without error.

If you have unset XDG_SESSION_COOKIE in your ~/.bashrc explicitly, that is user mistake. I'd say this is not a bug.

bastafidli (ubuntu-bastafidli) wrote :

I have found out new way how to trigger this bug which I haven't seen reported before.

I had a working single seat installation of Hardy 8.04.1 and everything was working just fine. I have switched to two seat installation using the following FAQ

and when two seats are active then the Unlock buttons in users-admin, time-admin and possibly others is always disabled. When run from console I get

sudo users-admin
[sudo] password for miro:

** (users-admin:24529): CRITICAL **: Unable to lookup session information for process '24529'

You still used sudo in that example. What if you just run users-admin
(without sudo) while in multi-seat mode?

bastafidli (ubuntu-bastafidli) wrote :

Sorry, I forgot to paste that example. There is no special message on the console, the dialog appears, the Unlock button is present but still disabled. The same is true for time-admin, network etc. Basically in multiseat mode the system cannot be managed at all using the gui tools.

tags: added: button disabled unlock
bastafidli (ubuntu-bastafidli) wrote :

I can confirm that this bug is still present in Jaunty 9.04 when used as multiseat configured as described here

tags: added: multiseat

The thing is, in the gdmflexiserver case and the su case, they really are separate sessions, so piggy backing off the other parent session isn't right.

Right now ConsoleKit doesn't have great support for nested sessions, but that's really what we need I think.

Changed in consolekit:
importance: Unknown → High
Mikko Rantalainen (mira) wrote :

I see that this is marked "invalid" for "sudo". Is this really correct?

$ env | grep XDG_S
$ sudo -s
# env | grep XDG_S
# exit
$ sudo su
# env | grep XDG_S
# exit

Is the difference between "sudo -s" and "sudo su" intentional?

Changed in consolekit:
importance: High → Unknown
Changed in consolekit:
importance: Unknown → High
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

Remote bug watches

Bug watches keep track of this bug in other bug trackers.