Re: xscreensaver vs gnome-screensaver

Hi Mahmood,

Sorry for the long delay.

Mahmood Ali - Sun Microsystems wrote:
William Jon McCann wrote:
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.


I was baffled with this myself when i was told that this is the proper way to implement PAM. The reason behind this is what Alan has pointed out, i.e. authentication should not depend on X-events to occur. So, suppose you have a smartcard enabled system. You do not move the mouse or keyboard in that scenario, you simply insert the smartcard in the reader. Now, currently xscreensaver/gss will keep on waiting for a keyboard or mouse movement before they would initiate PAM authentication. And it would be silly for user to insert the smartcard and then move the keyboard or mouse, to initiate conversation with PAM. Similarly, fingerprint readers, you are supposed to stick your finger in the reader, and if PAM is not already sitting in conversation function, no way for the finger reading PAM modules to get control and proceed with authentication as they do not have execution control and waiting for X-events i.e. someone to hit the keyboard or mouse.

This all falls back to the logic of PAM doing the conversation with the user as soon as when the screen is locked, and not the locking program trying to control when PAM needs to be activated.

OK, I agree that we shouldn't require mouse or keyboard activity to unlock the screen when a smartcard or other PAM enabled device is used. However, I think it may be a little premature to start discussing the implementation details of how we achieve this. Alan pointed out that we might be able to have something use org.gnome.Screensaver.poke to simulate key/mouse activity or maybe it is better to listen for a SmartCardInserted or whatever event from HAL and request an unlock dialog - I'm not sure. I guess the point is that I don't see why we have to live in a PAM mainloop for this to work. I think we can make it work.

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.

This is the confusing part for me in regards to gss. So, gss daemon is a non privileged process (i.e. no setuid root process) and the dialog process is setuid root(?) atleast initially before it gives up its privileges?? unlock dialog does all the work of authentication, including PAM code which requires setuid root to be set and the GUI (gtk based?? which will exit if setuid root is set)??

Right, the privs are dropped before UI is initialized.

The issue is that a proper implementation of PAM forces an inter-twined relationship with the unlock GUI and the pam code. It is not like before where you drop privileges, fire up the GUI, obtain the password, get privileges back, then launch PAM with the obtained password. This is not how logic flows with the proper PAM implementation. It is more like have privileges, run PAM, in pam conversation function, if PAM needs prompt strings displayed, you launch a gui displaying info, if PAM needs input the GUI provides input, and this cycle goes on, untill all PAM modules are satisfied with input and declare if it is ok to unlock the screen. There is a lot of back and forth. You be getting and giving privileges while in PAM conversation function. Will have to investigate more to figure out if this approach of giving/getting privs while in pam conversation will work.

I'm not familiar with systems that require PAM clients to be setuid. My experience with this is limited I suppose. I guess if your system require the PAM bits to have privilege you might have to use a helper to do the PAM communication and some kind of IPC (DBUS?) between the helper and the dialog. Not sure. Haven't really looked into it much yet.

What works is decoupling the gui and PAM code. GUI is separate non privileged gtk code, PAM code is in the daemon which is privileged. If the GUI crashes or gets killed, daemon is still up and screen locked.

If you really do need it decoupled then putting it in the daemon is not the only option.

Just curious as to why did you have a separate gnome-screensaver-dialog process. Why didnt you leave it all to be a single process? :-)

For privilege separation and to make it more robust by doing most of the complex operations in separate process. So if user-switching or anything else in the unlock dialog, including gtk causes a crash then the screen lock remains intact. There are also some other benefits like not storing stale auth info in the no-PAM case. If you are a setuid friendly kind of system you can at least limit the setuid to the dialog process.

And Nalin, when PAM code runs it needs setuid root as some of the PAM modules go and get passwords from passwords file, and may need privileges to do various other things depending on the module. Having root privileges is a must for PAM to work, and i believe this has to be so for other vendors/OS's to provide unrestricted capability in terms of privileges the PAM module developer wants to develop.

Also, the race conditions between the helper gui and the daemon were a concern of Jamie. We had some issues initially where the screen is not blanked and the helper gui gets posted, and some typeahead keyboard issues in helper gui. But, both were fixed with minor changes, and besides it being really slow as we fork and exec everytime the GUI is needed, it works fine.

I'm sure there will be a number of technical challenges once this work begins.

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

Yeah right, the freaking thing doesnt work on solaris, well it does now but had issues initially and may still have some.

That doesn't mean it isn't awesome. It just means Solaris is behind the curve. ;) I'm glad to see it is catching up.

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? ;)
for users      - simple, defaults work, pretty
for admins     - lockdown, control
for developers - nice desktop neutral API, rich data and signals, standarizable themes interface

Hmm...although you nailed it when you guessed i havent had tried gss yet ;-) and i may change my mind once i do get to try it, but for now from your answer, it seems gss is more of a tool for admins. This is where it provides the value compared to xscreensaver. Other things are debateable in my opinion. Not, that i like xscreensaver, it made me pull my hair many times, and Jamie, was a bit hard to deal with, specially after he opened his night club.

But, after spending some time dealing with bugs in xscreensaver, i had come to a hard realization that screensavers are mostly unwanted programs. Got resource intensive through the use of hacks and gained even more bad rep with the sys admins. In this respect, having sys admin specified policy to override user's preference will win points and perhaps the right direction to go in, and the capability to switch/logout the users once the screen is locked is again a very practical and useful feature.

Pretty insightful observations.

ps: Jon, rumor has it that you are not only going to follow the tradition of screensaver writers but up the ante on Jamie and planning on opening a gentlemen's club....dont develop amnesia and forget your old friends when that happens :-)

Unfortunately, as far as I know he didn't make his money off the screensaver. So don't hold your breath. :)

Thanks Mahmood. I think you'll find that the authentication code is almost identical to what you are familiar with in xscreensaver so please dig in. If you can please keep this list informed of your progress.

Thanks much,

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