Re: [gdm-list] GDM smartcard hack

["Geoff Elgey" <Geoff Elgey quest com>]

G'day,
 
Thanks for the reply. 

> It might be possible to get this sort of thing to work with 
> one PAM module, but probably better to have separate modules 
> for keyboard entry and SmartCard.  PAM isn't really designed 
> for a single PAM module to handle multiple kinds of authentication.

I did gloss over a lot of stuff in my original message. The PAM modules
I have that handles smartcard handles two cases: smartcard
authentication only, or smartcard authentication with fallback to the
next module in the PAM stack (which is typically a password-based PAM
module). A different prompt is used for each case. Not technically pure
(in the sense that adding a fingerprint reader for example between the
smartcard and password modules on the stack would be tricky), but
sufficient for my purposes. 

[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?]

> 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. 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.

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.

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.

-- Geoff