Re: xscreensaver vs gnome-screensaver

[William Jon McCann <mccann jhu edu>]

Hi Mahmood,

Sorry for the long delay.

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

> --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 :-)

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,
Jon