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

[Bob Doolittle <Robert Doolittle Sun COM>]

Brian Cameron wrote:
> Jeff:
>
> > I'm from Sun Beijing Desktop team. Now I'm trying to port
> > gnome-screensaver to Solairs.
> >
> > On Solaris, a process of the normal user can not authenticate users
> > through PAM, it must be a suid program or a root program. Since GDM
> > already has a process that can do that, do you think that
> > gnome-screensaver
> > can make use of the interfaces of GDM to authenticate users? If
> > possible, could someone give some hints how to do that?
>
> The GDM process that talks to PAM is gdm-session-worker. The PAM and
> Audit steps are a bit different for a normal login than for lockscreen,
> but it probably wouldn't be too hard for GDM to be made smart enough to
> keep track of which mode it is in and to handle these minor
> differences. I would say 95% of the PAM interactions are identical, so
> keeping all PAM-related code for login and lock screen in one place
> does seem like it would be more simple and maintainable in the long
> term.
>
> There are two approaches that I think could be used:
>
> 1) gnome-screensaver becomes a program which just keeps track of
> when the session is idle long enough to lock the screen, does
> the screen lock and shows eye-candy. When the user hits a key or
> moves the mouse, it would send GDM a D-Bus message telling it to
> displays the normal GDM login window to ask the user to
> authenticate. This would cause GDM to start the login dialog with
> the lockscreen PAM stack so it just asks for the password (or
> whatever the lockscreen PAM stack is defined to do).

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?

-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