Re: [gdm-list] GDM smartcard hack

[Bob Doolittle <Robert Doolittle Sun COM>]

Brian Cameron wrote:
> > [As an aside, even the smartcard only case still presents a "Username:"
> > prompt under GDM, at least with all the themes I have tried. Is it
> > possible to have a UI that only displays a prompt field when a PIN is
> > required? That is, after card insertion has been recognized?]
> >     
>
> You probably need to hack the PAM module if you want a different label.
> It'd be gross to change the prompt in the GDM GUI code, I'd think.
>   

What PAM module is generating this label?

Typically a username prompt is generated by a call to pam_get_user().
pam_get_user() will only generate the prompt if the PAM_USER item is
unset.  So, the way to avoid the prompt (assuming you know who the
user is) is to set PAM_USER.  If you intend to get the username off of the
card after unlocking it, I suspect you could temporarily set PAM_USER
to something bogus, then prompt for your PIN and do your authentication,
unlock the card, retrieve the *real* username, and set PAM_USER to
the correct value.  It should be harmless to have PAM_USER set to
some arbitrary junk temporarily within a PAM module, as long as it's
set properly (or unset, if authentication fails) upon return from
pam_authenticate().

And, it's been said many times on this list before - avoid doing *anything*
special inside of GDM regarding smartcards.  Don't you care about unlocking
existing sessions with smartcards also?  Typically you do, so it's best to
put whatever event mechanisms you need in a separate daemon that can
talk to your PAM module as necessary.  Then you can leverage that daemon
and your PAM module from other contexts such as screen savers.

If you must do something within GDM, try to make it minimal so you have
less to recreate when attempting to port the work to other contexts.

-Bob

> > > This PAM module (or a separate daemon or a GTK_MODULE loaded 
> > > into the GDM daemon) should be listening for SmartCard 
> > > insertion) and should shutdown and restart GDM with the new 
> > > PamStack configuration setting.
> > >       
> > Interesting -- I need to learn more about GTK_MODULE, if it can be
> > loaded in to the GDM daemon. 
> >     
>
> Actually gdm-binary doesn't use GTK_MODULE since it doesn't normally
> call gtk_main (unless it needs to pop up a GUI dialog after dropping
> down to the gdm user).  However, implementing a module structure
> that works like GTK_MODULE for GDM would be the way to do this, I think.
> Refer to the GTK+ documentation to learn about GTK_MODULE and how it
> is implemented.
>
> Note that AddGtkModules and GtkModulesList in the GDM configuration
> code only applies to the modules loaded for the GUI (gdmlogin,
> gdmgreeter, gdmchooser, etc.).
>
>  > Although shutdown and restart of GDM would
>  > be kinda ugly user experience, right? Blanking of the screen and
>  > bringing it all back up again? It would probably be easier to modify
>  > the PAM stack on the fly, and have GDM call pam_sm_authenticate() or
>  > even pam_start() again, although just what changes are made, and to
>  > which file, could prove tricky.
>
> The code you'ld probably want to modify is daemon/verify-pam.c, where
> the logic for interacting with PAM is located.  The hard part is
> notifying GDM when it actually needs to do this, since it might already
> be in the middle of a PAM interaction.  Perhaps adding a gdmflexiserver 
> --command (look for GDM_SUP in gdm.[ch]) option would work well here.
> I'd make it work so it requires authentication so that random users
> cannot tell GDM to keep rebuilding the PAM stack.  Or perhaps some
> other mechanism?
>
> But tearing down and restarting might be a good way to get it to just
> work in the short term, and then make it look pretty later.
>
>   
> > Currently I have a GDM configuration file setting that specifies the
> > location of a "PAM prompt service". If the setting exists, then the
> > service (shared library) is loaded dynamically when a PAM_PROMPT_ECHO_ON
> > or PAM_PROMPT_ECHO_OFF message is handled. This service is started just
> > before the gdm_slave_greeter_ctl (GDM_PROMPT, m) call and terminated
> > when that call returns (or perhaps it is better to add this login where
> > GDM_PROMPT is handled). In my previous post I just called this "start
> > smartcard thread", but really it is just a service that basically
> > provides another way to get an input from the prompt -- in this case,
> > card insertion is detected and returns an empty username. The PAM module
> > knows what do if it gets an empty username and it detects a card.
> > Actually, this could be extended to other mechanisms such as
> > fingerprint-readers, etc -- anything that can be made to emulate a
> > response to a PAM_PROMPT_ECHO_ON or PAM_PROMPT_ECHO_OFF message, really.
> >
> > But if there's a GTK module that can do something similar, then I'll
> > look into it.
> >     
>
> Yes, sounds reasonable.  I'd recommend using something like a
> GTK_MODULE.  I think Ray Strode from RedHat is also working on some
> SmartCard code that works using GTK_MODULE.  So perhaps you and he might
> want to trade emails and discuss, share code, or whatnot?
>
> He may respond to this thread, but if not, his email is:
>
>    rstrode redhat com
>
>   
> > BTW what do you mean by "restart GDM with the new PamStack configuration
> > setting"? Does PamStack mean the actual PAM stack (ie, the content of
> > /etc/pam.d/gdm) or are you referring to something within GDM? You
> > mention updating the GDM configuration file so I'm guessing the latter?
> > I'm using GDM 2.6.05 at the moment (since I am targetting what gets
> > shipped with RHEL4) and I don't see any "PamStack" in the code.
> > Apologies if I have misunderstood the reason why the GDM configuration
> > file should change.
> >     
>
> PamStack was added in 2.14.5.  I'd recommend using this version (the
> latest 2.16 release would be better) since it has code like this to
> support things like SmartCard, dynamic PAM stack modification, etc.
>
> The value of security/PamStack is passed in as the 2nd argument
> to the create_pamh call, so the name of the PAM module to use can be
> configured in the GDM configuration files, starting with GDM
> version 2.14.5.
>
> As I mentioned before, this value can be set per-display.  Refer to
> the GDM docs to see how to use per-display GDM configuration.
>
>    http://www.gnome.org/projects/gdm/docs.html
>
> Brian
> _______________________________________________
> gdm-list mailing list
> gdm-list gnome org
> http://mail.gnome.org/mailman/listinfo/gdm-list
>