I have a problem when my userid, and only my userid, has no Lock Screen menu item or applet.
I reported this problem against gnome-screensaver (BZ# 457147) but its not progressing so perhaps the problem should be reported against a different component?
What is really weird, and bothersome, is that this state (no Lock Screen menu item) doesn't get reset by: rm -rf .gnome .gnome2 .gconf .gconfd .metacity
Where else is per-user state kept ?
My system is x86_64 Rawhide.
*||*
John Ellson wrote:
I have a problem when my userid, and only my userid, has no Lock Screen menu item or applet.
I reported this problem against gnome-screensaver (BZ# 457147) but its not progressing so perhaps the problem should be reported against a different component?
What is really weird, and bothersome, is that this state (no Lock Screen menu item) doesn't get reset by: rm -rf .gnome .gnome2 .gconf .gconfd .metacity
Where else is per-user state kept ?
/tmp
-- Chris
Christopher Snook wrote:
John Ellson wrote:
I have a problem when my userid, and only my userid, has no Lock Screen menu item or applet.
I reported this problem against gnome-screensaver (BZ# 457147) but its not progressing so perhaps the problem should be reported against a different component?
What is really weird, and bothersome, is that this state (no Lock Screen menu item) doesn't get reset by: rm -rf .gnome .gnome2 .gconf .gconfd .metacity
Where else is per-user state kept ?
/tmp
-- Chris
No, tried that. its not in any file in /tmp or /var/tmp
On Thu, 2008-09-11 at 10:40 -0400, John Ellson wrote:
I have a problem when my userid, and only my userid, has no Lock Screen menu item or applet.
(having not looked at the bug)
Are you sure it's not a ConsoleKit interaction making the session think your user isn't at the console?
Jesse Keating wrote:
On Thu, 2008-09-11 at 10:40 -0400, John Ellson wrote:
I have a problem when my userid, and only my userid, has no Lock Screen menu item or applet.
(having not looked at the bug)
Are you sure it's not a ConsoleKit interaction making the session think your user isn't at the console?
Only if ConsoleKit is keeping per user-state. If I login at the console as any other user I get the Lock Screen menu item.
I just tried moving aside my home directorory, deleting my userid, removing everything in /tmp and /var/tmp, rebooting creating a new userid with the same name (but different user and group numbers), and it still has no Lock Screen!!!
Something is keeping information about userid "ellson" outside of /home/ellson, but what?
On Thu, Sep 11, 2008 at 7:30 AM, John Ellson john.ellson@comcast.net wrote:
Are you sure it's not a ConsoleKit interaction making the session think your user isn't at the console?
Only if ConsoleKit is keeping per user-state. If I login at the console as any other user I get the Lock Screen menu item.
Taking a quick look at the authorizations gui on my F9 system, you can in fact do grants and blocks for individual users, but I don't see anything in the list of possible authorization targets which is lock screen. Rawhide could have added that however.
I still don't understand PolicyKit/ConsoleKit well enough to help you track it down in the filesystem with 100% confidence. But I would suspect that you should look in /var/lib/PolicyKit/ and /var/lib/PolicyKit-public/ for per-user authorization rules if they existed.
Hope this helps.
-jef
Jeff Spaleta wrote:
On Thu, Sep 11, 2008 at 7:30 AM, John Ellson john.ellson@comcast.net wrote:
Are you sure it's not a ConsoleKit interaction making the session think your user isn't at the console?
Only if ConsoleKit is keeping per user-state. If I login at the console as any other user I get the Lock Screen menu item.
Taking a quick look at the authorizations gui on my F9 system, you can in fact do grants and blocks for individual users, but I don't see anything in the list of possible authorization targets which is lock screen. Rawhide could have added that however.
I still don't understand PolicyKit/ConsoleKit well enough to help you track it down in the filesystem with 100% confidence. But I would suspect that you should look in /var/lib/PolicyKit/ and /var/lib/PolicyKit-public/ for per-user authorization rules if they existed.
Hope this helps.
-jef
There is a /var/lib/PolicyKit/user-ellson.auths but removing it makes no difference. That file talks about using polkit-auth
Running polkit-auth as user ellson generates a long list of stuff: org.freedesktop.hal.dockstation.undock org.freedesktop.hal.device-access.sound org.freedesktop.hal.device-access.video4linux org.freedesktop.hal.device-access.cdrom ...
Where does it get this from? Removing /var/lib/PolicyKit/user-ellson.auths doesn't change the output. Running it in another user's account generates different, empty, output.
"polkit-auth --show-obtainable" doesn't offer any obvious token for enabling LockScreen.
On Thu, 2008-09-11 at 13:03 -0400, John Ellson wrote:
Jeff Spaleta wrote:
On Thu, Sep 11, 2008 at 7:30 AM, John Ellson john.ellson@comcast.net wrote:
Are you sure it's not a ConsoleKit interaction making the session think your user isn't at the console?
Only if ConsoleKit is keeping per user-state. If I login at the console as any other user I get the Lock Screen menu item.
Taking a quick look at the authorizations gui on my F9 system, you can in fact do grants and blocks for individual users, but I don't see anything in the list of possible authorization targets which is lock screen. Rawhide could have added that however.
I still don't understand PolicyKit/ConsoleKit well enough to help you track it down in the filesystem with 100% confidence. But I would suspect that you should look in /var/lib/PolicyKit/ and /var/lib/PolicyKit-public/ for per-user authorization rules if they existed.
Hope this helps.
Why don't we stop all this blind guessing, and attach a debugger to the panel instead ? It would be so much easier...
Matthias Clasen wrote:
Why don't we stop all this blind guessing, and attach a debugger to the panel instead ? It would be so much easier...
Because I'm not a gdb expert, and I don't know what to look for in gnome-panel, or even why you think gnome-panel is the place to look?
If you wouldn't mind helping out with some more detailed suggestions, perhaps offline from this list, then I'm willing to try.
On Thu, 2008-09-11 at 14:59 -0400, John Ellson wrote:
Matthias Clasen wrote:
Why don't we stop all this blind guessing, and attach a debugger to the panel instead ? It would be so much easier...
Because I'm not a gdb expert, and I don't know what to look for in gnome-panel, or even why you think gnome-panel is the place to look?
If you wouldn't mind helping out with some more detailed suggestions, perhaps offline from this list, then I'm willing to try.
You probably want to break in panel_lock_screen_action_available and see what is going on there.
Matthias Clasen wrote:
[ gnome-panel ]
[ gnome-panel ]
You probably want to break in panel_lock_screen_action_available and see what is going on there.
Thanks for that clue. I've found my problem.
It turns out that there is a new feature: System -> Preferences -> Lockdown Editor which is provided by a package called "pessulus" (Obvious! How could I miss it!)
This gui allows the administrator to enable/disable certain features for each user. It stores the setting away somewhere in gconf magic-land. I couldn't work out where but it definitely isn't under $HOME.
I think what happened was that I installed this new "pessulus" package, then tried it out from the command line to see what it did, randomly clicked on some buttons, then promptly forgot about it and didn't know how to get it back.
-
Chris Snook -
Jef Spaleta -
Jesse Keating -
John Ellson -
Matthias Clasen