Re: [gdm-list] GDM smartcard hack

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

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.


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.

gdm-list mailing list
gdm-list gnome org

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