|
William Jon McCann wrote: Sure, i have it working on xscreensaver, although it may still be missing some cases but is much better than the existing code.This all sounds very cool. Perhaps this can be the goal for the next release cycle. Want to send me a patch? 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.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? 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.
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)?? 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. 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. 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? :-) 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. Yeah right, the freaking thing doesnt work on solaris, well it does now but had issues initially and may still have some. 8) And finally, what was the motivation for yet another screen saver? How is gss different/better/worst than xscreensaver? 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.Saved the best for last did ya? Let me guess, you haven't tried gnome-screensaver yet? ;) 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. --mahmood 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 :-) |