Re: [gdm-list] Screensaver Solution Discussion

[Jörg Barfurth <Joerg Barfurth Sun COM>]

Bob Doolittle schrieb:
> 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

No. Not yet. An individual authentication transaction is started by 
pam_start (and ended by pam_end). That means that this must be called 
every time the screen is locked. You can't reuse the same PAM handle 
during the whole lifetime of a session.

> > 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.

I see various pieces in this discussion. This step IMHO must be somewhat 
like this:

- Have GDM start a 'lock session' and a privileged PAM worker process. 
If possible, start/activate a different X session for the lock. On the 
console that is possible through VT, but there should be a hook for Sun 
Ray or similar systems to do the same by different means (*). If 
switching display is not possible, use the session display (current/old 
behavior).

- In the lock session, start a full-screen window, grab what you can and 
 show eye candy (if configured).

- In the lock session. Prepare or start, but don't show, the unlock 
greeter. This may or may not be deferred until the pam_conv callback is 
called. If following the current gdm model, it would not be deferred. 
Even when the pam_conv callback is called, the greeter window should not 
be mapped until step 3.

- In the PAM worker call pam_start/pam_authenticate. The PAM worker 
controls the unlock greeter the same way the gdm slave controls the 
login greeter. The goal is to reuse much code between gdm slave daemon 
and unlock PAM worker and similarly between the greeters. Whether that 
is best done by using the same binary with different parameters, by 
extracting common code into shared object or by some other means remains 
to be seen.

(*) IMHO, that would be preferable to the current behavior where Sun Ray 
has to simulate this from a PAM module. But for starters the PAM usage 
should be set up to work as indicated with VT and allow Sun Ray to 
function as it does.

> 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).

When waiting for such a smart card reader, we still should show 
instructions to use the card to unlock, if the user moves the mouse or 
presses keys. Unfortunately the pam_conv mechanism isn't well suited for 
this, but that is a different issue.

> 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.

If we try to switch displays first, then that problem is solved whenever 
we can switch displays.

The issues with blocking X operations stalling the PAM transaction would 
probably be solved by having all X interactions separated from PAM 
processing through as process boundary (lock-session <-> pam-worker).

> 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).

pam_open_session would not be called in a re-authentication transaction. 
I don't think PAM has a place in starting the 'unlock session', but even 
if it did, that would be a separate PAM transaction.

- Jörg

--
Joerg Barfurth           Phone: +49 40 23646662
Software Engineer        mailto:joerg barfurth sun com
Desktop Technology
Thin Client Software     http://www.sun.com/software/sunray/
Sun Microsystems GmbH    http://www.sun.com/software/javadesktopsystem/

Sitz der Gesellschaft:
Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel
Vorsitzender des Aufsichtsrates: Martin Haering