Administrative tools with PolicyKit's "Unlock" button remain locked (with Unlock button disabled) when invoked via gksu{,do} (i.e., as root)

Bug #272400 reported by SoloTurn
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
policykit (Ubuntu)
Confirmed
Low
Unassigned

Bug Description

i am running ubuntu intrepid 64bit and the bug reported and closed in #236516 is still / again here:

under "system>administration>users and groups" the add-user button is inactive (gray).
i also cannot change settings of my own account, as if i am some user, but i am THE user..
everything is grayed out. so i could not, by any means add a new user, nor change my own settings.
when launching this application through xterm
$ sudo users-admin
i get following message:
** (users-admin:15450): CRITICAL **: Unable to lookup session information for process '15450'

contrary the following works:
 xhost +local:
 sudo su -
 export DISPLAY=:0
 users-admin

Revision history for this message
Mackenzie Morgan (maco.m) wrote :

Is the Unlock button still visible and able to be used?

Changed in gnome-system-tools:
status: New → Incomplete
Revision history for this message
SoloTurn (soloturn) wrote :

on a different machine: yes. if this is really the solution, it is VERY not-intuitive.

Revision history for this message
Mackenzie Morgan (maco.m) wrote :

I think this is a PolicyKit bug, because I just tested with time-admin and users-admin. It's reproducible on both.

If run as root, the Unlock button is there, but it's disabled. Everything else (except Close) is also disabled as if it hasn't been unlocked, even though the application is running with root privileges already.

Changed in gnome-system-tools:
status: Incomplete → Confirmed
Revision history for this message
Mackenzie Morgan (maco.m) wrote : Re: Administrative tools with PolicyKit's "Unlock" button remain locked (with Unlock button disabled) when run as root

PolicyKit is meant to make it so that you don't have to run gksu before launching the apps, you can get permission afterward; however, that it makes it impossible to run it from gksu (and still be usable) is, in my opinion, a bug. If you run it from the menu, the Unlock button makes perfect sense.

Daniel T Chen (crimsun)
Changed in policykit:
importance: Undecided → Low
Revision history for this message
James Westby (james-w) wrote :

Hi Mackenzie,

Do you also get the

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

message when you run "sudo users-admin"?

Thanks,

James

Revision history for this message
James Westby (james-w) wrote :

Hi,

Could you also provide your /etc/PolicyKit/PolicyKit.conf file
to ensure that the problem is not with that.

Thanks,

James

Revision history for this message
James Westby (james-w) wrote :

Could you also provide the output of

  echo $XDG_SESSION_COOKIE

This may well be the same as bug 231246 it seems.

Thanks,

James

Revision history for this message
Mackenzie Morgan (maco.m) wrote :

Yes

Before sudo-ing and after, the output is the same:
$ echo $XDG_SESSION_COOKIE
b6b1b8a138c64c4d27f27d6748593228-1222036031.766596-486683345

Revision history for this message
Mackenzie Morgan (maco.m) wrote :

Yep, it's a duplicate, you're right.

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

Other bug subscribers

Remote bug watches

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