[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: what is keeping per-user state outside of user's $HOME ?



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.



--
John Ellson


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]