Re: gnome-xscreensaver (and some fast user switching)

[Shahms King <shahms shahms com>]

On Tue, 2003-12-02 at 03:36, Rodrigo Moya wrote:
> > 
> the only thing I'd like it to have would be to allow the user to create
> a new login on the auth dialog xscreensaver shows when it's running and
> a user moves the mouse/keyboard.
> 
> That way, you could lock your screen, but still allow a person to log in
> whit his/her own account.
> 
> cheers

I think this is the crux of the discussion.  How do we present a
reasonable interface to a "new" user sitting down to a workstation
someone else was logged in at.  If the workstation in question was just
left idle, we'll have the screensaver dealing with authentication and
switching users, but if the last user was responsible and selected
"Actions -> Log Out -> Switch Users" GDM will be responsible.  If
everyone used GDM, it would be a relatively simple solution of just
having GDM be responsible for the login box (toss up a greeter in
response to keyboard activity).  However, this isn't always the case. 
For whatever reason, not every GNOME user uses GDM. So, we need to be
able to handle a number of cases:

     1. manually changing to the VT (Ctrl + Alt + <Fkey>, chvt,
        whatever)
     2. coming to a "locked" workstation as a different user than the
        one who locked it (with the screensaver controlling the
        terminal)
     3. coming to a "switched out" terminal as a new user
     4. coming to a "switched out" terminal as a returning user

Neither 3 or 4 will be a problem if the workstation isn't using GDM (as
we rely on it for actually switching users, without GDM you can only log
out).  For 1 and 2, when not using GDM, the current situation is exactly
how it should work.  If we're not using GDM we can't switch users
anyway, so the only option is to disable the screensaver using the
current user's password.  The more I think about this, the more I think
it's in need of a freedesktop.org spec of some kind (for those
unfortunate people using KDE or KDM ;-P).  

Perhaps a series of D-BUS messages?
<thoughts type="wandering">
When the screensaver is presented with a situation where it needs the
user to authenticate, it sends out a message, essentially "DISPLAY x
needs an authentication dialog" to the registered display manager using
D-BUS.  I would assume that whatever "registration" entails, the mere
fact that it registers itself implies that it supports this protocol. 
If there isn't one, the screensaver can simply fall back to the current
situation.  Without registration of some sort the screensaver is in a
position where it has to wait for a response from a display manager and
can't show it's own login dialog until that times out.  Also, without
some mechanism for ensuring a unique display manager the screensaver may
get multiple responses, might end up with multiple display managers
wanting to auth users and (more importantly) the screensaver and user
cannot trust the display manager to have actually authenticated the user
or done something "untoward" with the username and password.

At this point the display manager is in charge of authentication.  Then
all the screensaver would have to do is listen for a *trusted* "unlock
screensaver" message from the display manager.  It doesn't matter which
VT the users login session is actually on, sending the message to the
right screensaver process is the display managers job.  Using the same
method we can expand the "screensaver message protocol" to include
things like "disable screensaver" (from say, totem), "lock screen",
"black screen", etc.
</thoughts>
-- 
Shahms King <shahms shahms com>