On Mon, 2008-01-07 at 14:52 -0600, Brian Cameron wrote:
> It isn't clear to me how you propose PolicyKit would be a part of
> the solution. Perhaps you could clarify.
Hmm, I thought I was repeating what everyone else already said :)
I'll draw a couple of ASCII diagrams. I don't want people to think of
these as processes, I'm not sure they all need to be, more ideas on
where things could go.
GDM Context +--------+ User Context
+--------+ | System | +-------------------+
| Screen |---| DBUS |---| Activity Monitor |
| Locker | +--------+ | User pref. widget |
+--------+ +-------------------+
| +-----+ |
+--------| X11 |---------------+
+-----+
So the screen locker itself would exist outside of the user's world. It
would provide a DBUS API that would have things like setting the
screensaver and methods to lock and unlock the screen. These APIs would
then be controlled by PolicyKit, so if the activity monitor would want
to unlock the screen because the mouse moved that method may be locked
by PolicyKit. PolicyKit would then pop-up the password dialog to unlock
the screen.
This would then put us in a place that if the PolicyKit authentication
dialog could be made bullet-proof we would inherit that on the screen
saver side of things. There is also no reason that those who wanted to
could run the screen locker in the user context.
I think that PolicyKit is mostly focused on giving admin access, but I
see no reason that it could be used to give local user permission also.
Especially as it already had integration with ConsoleKit, so it should
know the logged in user.
--Ted
Attachment:
signature.asc
Description: This is a digitally signed message part