Re: [gdm-list] gnome-screensaver authenticates users through GDM

[Bob Doolittle <Robert Doolittle Sun COM>]

Jeff Cai wrote:
> > Please don't require a mouse-movement or other user interaction to 
> > initiate the authentication for unlock.
> > Why not do it immediately?
> >
> > Requiring user interaction makes it impossible to automate unlocking 
> > a session via the PAM stack, which can be very useful at times if 
> > there is some method of authentication occurring outside of the 
> > session itself (e.g. Sun Ray Non-SmartCard Mobility).
> >
> > IMO a screen saver should call pam_authenticate immediately when the 
> > screen is locked, to allow for such mechanisms. What would be the 
> > purpose in waiting?
> I think not pam_authenticate, it should be pam_start that is called 
> immediately. pam_authenticate needs the user gives the password.

pam_start is typically called during application initialization. It 
doesn't cause any user interaction, and it only needs to be called once, 
no matter how many times the screen is locked/unlocked.

pam_authenticate is called each time an app is ready to authenticate 
(e.g. in order to unlock a screen).

So yes, as soon as a screen is locked it is ready to become unlocked and 
therefore pam_authenticate should be called right away, although as Alan 
suggests you may wish to delay displaying the unlock GUI in the 
conversation function until some user action occurs e.g. mouse movement 
or keypress. There still exists the possibility that a PAM module may 
wish to unlock the screen without calling the conversation function or 
waiting for any X-based activity (e.g. some smartcard interaction 
external to the controlling keyboard/mouse).

Thanks,
  Bob

> Jeff
>
> > -Bob
> >
> > > This approach has many advantages. It means that only GDM needs
> > > to know about how to present the authentication dialog and handle
> > > PAM interactions. Having a single program handle the GUI is nice
> > > since this means that there is only a single dialog that needs to
> > > be made to work with a11y. Since GDM has good a11y support, it
> > > would be nice to leverage that.
> > >
> > > Another advantage is that on the console, this could be written so
> > > the authentication dialog screen is presented on a separate VT and
> > > runs as the "gdm" user, providing better TrustedPath security. This,
> > > for example, ensures that the authentication dialog is not using
> > > the same Xauth cookie as the user's session, avoiding any possible
> > > interference or snooping from a userland program.
> > >
> > > 2) gnome-screensaver just calls gdm-session-worker D-Bus interfaces
> > > to do the actual PAM interactions. You really do not want any
> > > program to be able to access these interfaces, so it would need
> > > to be implemented in such a way that only "approved" programs
> > > like gnome-screensaver could call these interfaces. This approach
> > > has the advantage of consolidating the PAM code in one place, but
> > > means that gnome-screensaver still needs to manage all GUI related
> > > things such as a11y. Also, this solution would not improve the
> > > TrustedPath situation at all.
> > >
> > > I imagine that new D-Bus interfaces would need to be added to
> > > gdm-session-worker to make this work, but I'd think it should be
> > > possible. And it could be a step towards implementing solution #1
> > > in the long-term.
> > >
> > > > I've heard that Jon McCann had ever planned to integrate the functions
> > > > of gnome-screensaver into GDM. But it may need a long time. So before
> > > > that, as the first step, GDM can provide PAM authentication
> > > > interfaces that allow others use them.
> > >
> > > At the GUADEC in Istanbul, Jon suggested that solution #1 above was
> > > something that he was thinking about implementing, though I think
> > > Jon is more focused on gnome-shell these days.
> > >
> > > Brian
> > > _______________________________________________
> > > gdm-list mailing list
> > > gdm-list gnome org
> > > http://mail.gnome.org/mailman/listinfo/gdm-list