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

[Jeff Cai <Jeff Cai Sun COM>]

On Fri, 2010-01-15 at 10:02 -0800, Alan Coopersmith wrote:
> Brian Cameron wrote:
> >    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.
> 
> Running unlock on another X server actually provides even more benefits:

Currently, before a user logs in GNOME, I find root user's Xorg keeps
running. Why it is not a normal user's X server like 'gdm'?

If the screensaver program is put into GDM, after a user logging in, two
X servers may be keep running. One is 'gdm', another is the logged in
user. Will this consume more system resource? thus affect the system
performance?

Jeff
 
> 
>  - allows screen lock to work even if another program has grabbed the
> 	mouse or keyboard on the main server (no more failure to lock
> 	because a menu is popped up)
> 
>  - if the terminate-server keystroke (Ctrl-Alt-Backspace) is enabled,
> 	would not kill the programs of the logged in user without
> 	authentication
> 
>  - if the user is running accessibility helpers that provide a history
> 	function, you could get a clean set running that don't show what
> 	words the user commonly enters via the helper
> 
>  - greatly simplifies the mess of having to deal with figuring out which
> 	user programs to allow to display in front of the screensaver
> 	(accessibility helpers), and which to force behind (like notification
>  	popups showing your new e-mail or chat messages)
> 
> >> 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?
> > 
> > Yes, it does make sense to show the lockscreen immediately, and
> > after a timeout show the eye-candy, that's true.  That's how lock
> > screen works currently, I believe.
> 
> Sun's fork of xscreensaver currently does this and it annoys users.
> If we were redesigning it today instead of moving to gnome-screensaver,
> the path I'd take would be to start the pam conversation immediately,
> but don't show the authentication dialog until the PAM conversation
> prompts for user input and the input is non-idle - for the common case
> of unlock with a password, this would appear to the user as not asking
> for a password until they move the mouse, even though the PAM conversation
> may have been running for hours, but would allow cases such as smartcard
> authentication to proceed when the smartcard was inserted without having
> to hit the mouse too.
>