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



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:

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

-- 
	-Alan Coopersmith-           alan coopersmith sun com
	 Sun Microsystems, Inc. - X Window System Engineering



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]