Re: xscreensaver vs gnome-screensaver

[William Jon McCann <mccann jhu edu>]

Hello Mali,

Here's a update on some of your concerns and questions.

mali wrote:
> Hello Jon,
>
> Per your suggestion i am sending this email with concerns on 
> xscreensaver code, and wanted to bring them to your and folks in 
> screensaver-list's attention as they may apply in gss as well:
>
> 1) PAM should be driving the unlock GUI instead of the GUI driving the 
> PAM code. In xscreensaver a serious flaw of logic is the assumption that 
> a locked screen will always require a username and password to unlock. 
> This is not always true. We have PAM modules which require no 
> interaction/input from the user. We also have PAM modules that prompt 
> you for ldap password instead of your login password. We also have a PAM 
> module which asks for a PIN instead of a password. The point is anyone 
> can write a PAM module that may ask anything like move your eye to the 
> scanner or what color underwear you are wearing, although i am not sure 
> how you be able to authenticate if the user is really wearing the 
> appropriate corporate subscribed underwar ;-) But, this is the whole 
> purpose of pluggable authentication modules, they can ask or not ask for 
> anything, no assumptions about what is going to be asked can be made.
>
> xscreensaver PAM code currently assumes a user will only enter a 
> password and without waiting for PAM, posts a unlock GUI and fills in 
> the username and prompts for a password, everything hardwired. Once the 
> user enters the password string, PAM code is then invoked. Instead, what 
> should really happen is before posting the unlock GUI, PAM needs to be 
> started and if PAM conversation function requires a input and provides a 
> string to prompt the user for, this string needs to be posted on the 
> unlock GUI as a prompt string. If any input is required from the user 
> that input is gathered and passed to PAM, which may still require other 
> inputs from the user, so no assumption about the number of inputs 
> required by PAM modules can be made as well. It can keep asking for 
> things and the GUI should be able to handle it.

In CVS HEAD I've completely reworked the way authentication is done. 
The authentication backend now drives the GUI.  Unfortunately, I haven't 
really been able to test this very well because I have a pretty basic 
PAM configuration on my systems.

> 2) As soon as the screen gets locked pam_authenticate needs to be called 
> and code should loop inside the pam_conversation function. Currently, 
> pam_authenticate gets called only when a user moves the mouse or 
> keyboard while the screen is locked.

This hasn't been changed.  I'm still not sure it is really necessary.

> 3) Solaris has auditing code for PAM which needs to be added. We need to 
> explore if other OS's have their own flavor of auditing code for PAM. 
> This needs to be looked into more extensively to provide a unified solution.

I'd appreciate a patch for this.

> 4) For audit code to have any validity, unlocking should not fall back 
> to the mechanism of comparing passwords to /etc/password entries and 
> authenticating without PAM. Only PAM should be the authentication policy 
> and no root passwords be allowed to unlock the screen, breaks auditing 
> again. If authentication through PAM fails, screen is not unlocked.

This is fixed in CVS HEAD.  The authentication backend is configured at 
build time and fallbacks are not allowed.


By the way, what happened to those patches you promised ;)

Anyway, I'd appreciate it is you and others could really give this a 
good test and let me know what you think.

Thanks,
Jon