Re: [gdm-list] Screensaver Solution Discussion

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

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

My point was that if the currently active 'session' is waiting for 
anything, it needs to show an unlock dialog with some sort of 
instructions or feedback when the user moves the mouse or presses a key. 
This is needed so that the user sees that this is a locked screen rather 
than a dead display. This really is independent of the current state of 
the PAM transaction or whether pam_conv has been called to show a prompt.

If the locked user session is inactive while locked, with another 
session (greeter session on VT, Sun Ray 'hotdesk' session) taking 
control over the display hardware, then that session is the one that 
needs to provide feedback for user actions, independent of the current 
state of its PAM transaction. And the real user session should not show 
any unlock dialog when it becomes reactivated, not even for a fleeting 
moment.

For the user session that distinction is somewhat analogous to the 
distinction between normal autologin - no user interaction, no GUI 
should show at all - and other forms of login without prompt but with 
greeter - login with smartcards or fingerprints, user-triggered 
autologin (AutologinShowGUI=1), maybe more (timed login is a somewhat 
different beast).

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

Well, there obviously is pam_allow, which is used in the standard 
gdm-autologin stack. But there is a difference between non-prompting 
modes that still wait for user action and modes that do unlock or login 
without any inetraction (except at most in error cases).

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

So that leaves open what gnome-screensaver does to the display in the 
user session while that other VT session is active. If gnome-screensaver 
knows that the user session becomes inactive (detached from its seat), 
then it does not need to cover screen contents or grab the X server at 
the X11 level. OTOH this presumes that VT switching does not care about 
X grabs.

> I'm not clear on how that would work and where the PAM context for the 
> VT authentication resides. 

I'd assume that this is within gdm or something spawned by gdm.

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

The simplest solution might be: the user session VT is not reactivated 
until authentication is complete. Attempts to reactivate it are 
redirected to activate the unlock session instead.

If that doesn't work or isn't sufficient: if there is a new dbus 
protocol telling gdm to start an unlock session on a VT, then that 
protocol can contain a way to return the authentication status.

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

Yes, bridging of credentials is an issue for such a design. This goes 
both ways:
- PAM modules may need existing credentials or environment of the user 
to reauthenticate the user.
- PAM modules that refresh credentials need a way to inject the 
refreshed credentials into the session.

This probably means that this can't be solved without changing existing 
modules. The new framework needs to:
- Make user session environment available to the unlock session.
- Provide ways for the unlock session to access the user session (home 
directory, dbus session bus, X server). But not the other way around!

The modules need to be changed to work with data with the original 
session where appropriate instaed of manipulating the current session 
context.

Note that for unlock, the 'within the context of the user desktop 
session' is already much more limited than in the login case: the 
session will not inherit anything from the screensaver process, so the 
session context can't be changed from truly within.

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

That certainly needs to be kept in mind when looking at any proposed 
architecture for this, but may not even be a problem for some reasonable 
approaches.

- 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
Vorsitzender des Aufsichtsrates: Martin Haering