Re: xscreensaver vs gnome-screensaver

[William Jon McCann <mccann jhu edu>]

Hello Mahmood,

Thanks for sending this message.  It is good to get this all out into 
the open.  I've commented below.

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.

This all sounds very cool.  Perhaps this can be the goal for the next 
release cycle.  Want to send me a patch?


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

Why?

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

Sounds fine to me.

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

I don't really have any objection to this.  Perhaps other vendors have 
experience with this?


> 5) I am not sure if gnome-screensaver is setuid root program(?), and it 
> has to be, to read /etc/password and make PAM calls, then how is it 
> handling the unlock GUI based on libgtk, as libgtk exits if a setuid 
> root program calls any functions in libgtk. Perhaps, it is caching the 
> password, then giving up root privs before making gtk calls, like 
> original xscreensaver written by Jamie used to do. This may not work for 
> PAM, as PAM gets invoked much later and may require interaction with the 
> user as described in 1) above.
>
> In xscreensaver the unlock GUI which is gtk based was turned into a 
> separate helper program by ximian. This helper GUI ran with no 
> privileges and would only get user input and pass it to the xscreensaver 
> daemon through a pipe. This did upset Jamie, is slow and potentialy can 
> cause race condition along with other havocs etc. Apart from it being a 
> lot slower, it has worked fine on solaris. Besides this, i dont see any 
> other way out of this unless you ditch gtk and pick java or some other 
> toolkit with accessibility support in it and the new toolkit/library 
> doesnt mind to be a setuid root program. Or somehow tricking gtk by 
> giving up privileges before making gtk calls and setting them back again 
> when using PAM, i am not sure if this is doable??

One of the nice things about gnome-screensaver is that the daemon 
process (gnome-screensaver) doens't know anything about authentication. 
 This is all done withing the gnome-screensaver-dialog process.  This 
process works basically the same way xscreensaver does - by initializing 
and then dropping privileges.  There is also support for using a 
authentication helper program.


> 6) Not sure why a heavy weight library like dbus is chosen to provide 
> idle time instead of getting xidle extension in Xserver to provide when 
> to lock screen? What are the advantages of using dbus?

DBUS is far from heavy weight and happens to be completely awesome. :)

There are many advantages to using DBUS I don't have time to list them 
all.  Some are: a clean/abstract API that doesn't depend on X11, process 
lifecycle tracking (important for inhibiting the screensaver), a desktop 
neutral interface, a bus on which to send signals when properties/states 
change, etc.

> 7) Power management by xscreensaver and people using xset commandline 
> while xscreensaver is running in the background to change dpms values, 
> user changed values through xset should not be overriden by 
> xscreensaver/gss?? Is this a reasonable request from the users?

Power management is now handled by gnome-power-manager - not the 
screensaver.  gnome-power-manager provides a nice DBUS API for using 
DPMS.  However, I don't think it is a reasonable request that users use 
xset to control DPMS.


> 8) And finally, what was the motivation for yet another screen saver? 
> How is gss different/better/worst  than xscreensaver?

Saved the best for last did ya?  Let me guess, you haven't tried 
gnome-screensaver yet?  ;)

I've tried to list some reasons here:
http://live.gnome.org/GnomeScreensaver
http://live.gnome.org/GnomeScreensaver_2fFrequentlyAskedQuestions

In short:

for users      - simple, defaults work, pretty
for admins     - lockdown, control
for developers - nice desktop neutral API, rich data and signals, 
standarizable themes interface

Thanks,
Jon