Re: [gdm-list] Screensaver Solution Discussion

[Bob Doolittle <Robert Doolittle Sun COM>]

Jörg Barfurth wrote:
> Bob Doolittle schrieb:
> > 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.

This was just an example of a 3rd-party PAM module that never calls 
pam_conv. We don't get to define the behavior of a 3rd-party PAM module 
(maybe the smartcard reader has a LED display showing instructions and 
chooses therefore not to use the X display to interact with the user, or 
maybe it's a fingerprint reader that users are trained to put their 
finger on when it lights up, or ...). The point is that a PAM module may 
never call the conversation function. There's nothing in the PAM spec 
that requires it to, and one can imagine scenarios where it may not be 
necessary. That means we must design around the fact that it's optional. 
Sun Ray provides the only real-world example of such a module that I'm 
familiar with, but like any of us I'm only familiar with a small 
fraction of the real world ;)

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

That would be fine, but that's not what Jeff is proposing, AFAICT... The 
proposal is for gnome-screensaver to use D-BUS to interact with GDM to 
initiate a VT from within the user desktop session context I believe. 
I'm not clear on how that would work and where the PAM context for the 
VT authentication resides. How does gnome-screensaver, within the user 
desktop session, receive the PAM authentication status when 
authentication on the VT has completed, unless PAM is running within the 
gnome-screensaver context or some new protocol is devised to pass that 
status back somehow? Note that technically PAM unlock authentication is 
supposed to occur within the context of the user desktop session. Some 
unusual, complex PAM models may fail if this is not done (I've heard 
that AFS uses one such model). The dialog can be in a remote session, 
however, and that's the primary goal here. My concern was simply that if 
gnome-screensaver, in the user session, tries to do *anything* on the 
local display whatever thread initiates that activity may block due to 
some other application's grab. So either we need to avoid interacting 
with the local display entirely or at least avoid doing that in whatever 
thread is going to control the authentication activity on the VT.

-Bob