Re: [gdm-list] Screensaver Solution Discussion

[Bob Doolittle <Robert Doolittle Sun COM>]

I've annotated your steps below with more specific PAM invocations:

Jeff Cai wrote:
> I summarized the steps about how screensaver works. Because a user can disable VT, 
> also because VT has not been supported on some platforms yet, for example SUN Sparc,
> we will handle both situations separately.
>
> 1. After the user logs in, the user's gnome-screensaver (user session) process will
> start.
>   

pam_start() should be called

> 2. When gnome-session tells that the session is idle,
> gnome-screensaver
> will start a full-screen window and grab the keyboard and the pointer,
> that is to say, the user's session is locked.
>
> gnome-screensaver tells GDM that the user's session is locked. GDM will 
> start initializing PAM and creates the unlock dialog if VT is
> enabled.
>   

Potentially gnome-screensaver's pam_conv() function may be called. Your 
steps below assume that it is.

Don't forget however that the pam_conv() function may never be called if 
a PAM module marked as "sufficient" on the auth stack returns 
PAM_SUCCESS before any later PAM module invokes the conversation 
function. This could happen for any sort of device that does external 
authentication independent of the conversation function, such as a 
smartcard reader that has a built-in PIN pad which doesn't require any 
X-based dialog/interaction, for instance. In such a case none of the 
below steps would occur (no unlock dialog ever displayed, no waiting for 
user mouse/kb event).

It's crucial in this model that no local X server grab affect the 
ability for gnome-screensaver to interact with another VT. I imagine 
there's no issue here but I raise this point just in case. If there is a 
grab in effect by some other application (e.g. firefox has a menu pulled 
down) and gnome-screensaver performs any sort of X operation on the 
local display that thread will *block*. This is the sort of 
vulnerability we are trying to resolve by utilizing a different VT for 
authentication.

I'm not going into the details about calls to pam_setcred (REFRESH), 
pam_acct_mgmt, and pam_open_session (this last call may not be required 
for gnome-screensaver, although perhaps when it interacts with a new VT 
it is? You'd need to check with a better PAM expert than I on this).

-Bob

> 3. If the user moves the mouse or hit the keyboard
>   
> 3a. If VT is enabled, gnome-screensaver will ask GDM to show the
> unlock
> dialog on another DISPLAY, and ask VT manager to switch to that DISPLAY. 
> Then the user inputs the correct password, GDM tells gnome-screensaver to
> destroy the window and release the keyboard and the mouse. Do the VT switching
> to the user's DISPLAY.
>
> 3b. If VT is not enabled, gnome-screensaver will show the unlock
> dialog, interacting with GDM on PAM authentication. If the user input the
> correct password, gnome-screensaver will destroy the lock window and release the keyboard and the mouse.
>
> For 3a, since a new GDM session is created, and GDM has already supported the accessibility, we don't need more work to do.
>
> But for 3b, we need consider to support the accessibility for the
> unlock dialog. Here I CCed a11y list in order to hear their opinions.
>
> Can I start a new at-spi-registryd for the unlock dialog? This daemon runs on a new DBUS session daemon listening on a new DBUS address.
> The unlock process and ATs will communicate with this session daemon, which will not affect the old daemon.
>
> Jeff
>
>
>
>
> _______________________________________________
> gdm-list mailing list
> gdm-list gnome org
> http://mail.gnome.org/mailman/listinfo/gdm-list
>