Re: xscreensaver vs gnome-screensaver

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.


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:

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


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