Re: [gdm-list] My questions



Martin Paljak wrote:

Working closely with smartcards (that is, opensc.org) I can say that this list is not bad either
for things that relate to GDM and smartcards login. What i can also tell is that most folks
at muscle and/or opensc mailing list (as muscle can be reduced to pkcs#11 and we have two different pkcs#11
related pam modules) tell you is to use one of the available pam modules OR to extend them ;)

What you're facing here most probly is what is often requested when smart card logon is investigated:

Something that would react on card insertion, read from there something that would result in a suername
and then only ask for a single pin and start the session.

Last time when i checked this was not possible with PAM. Because PAM, as writte nearlier, works on a
request-response mechanism and thus always wants first a username to start with.

I don't understand your conclusion here.  PAM is
request-response, but this has nothing to do with wanting a
username first.  There is no such requirement.  A username
request/response is no different from any other user
interaction, and there is no requirement that this be one of
the interactions.

A PAM module is perfectly happy to get a username in any way
you like.  Its only requirement is that it must use
pam_set_item() to set PAM_USER with the username once it is
acquired, so that any subsequent PAM modules (and the PAM
client itself) can retrieve the username later.  It's
possible that gdm itself calls pam_get_user() (sorry I don't
have access to source at the moment) before calling
pam_authenticate(), but there's no requirement for that -
this can be (and usually is) done in PAM service modules.
If gdm does this itself, I'd call it a bug.  If PAM_USER is
already set pam_get_user() won't do anything but return
its value, otherwise it will prompt the user first (and
set PAM_USER).

As for events and smartcards, it's not PAM that needs an
event delivery mechanism.  The event you want is a
smartcard-insert event.  Since MUSCLE is the
smartcard-access API, it should be MUSCLE's responsibility
to provide such an event.  A PAM module should just be a
consumer.

If *MUSCLE* provides an event notification mechanism for
smartcard-insert, then a PAM module can block waiting for
this event.  When it receives such an event, it can access
the card to read the username, set PAM_USER, then do
whatever other interactions are required.

-Bob




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