Re: [gdm-list] My questions

[Bob Doolittle <Robert Doolittle Sun COM>]

Philippe C. Martin wrote:

> I do not use Muscle as I have my own framework - I guess my first job is to 
> design a smart card event daemon based on that.
>  

Sounds like a good idea.  And some sort of callback/notification
mechanism that daemon can support for clients.

> > Yes and no.  PAM gets control when the client (GDM)
> > calls pam_authenticate().  This should happen when the
> > client is ready for authentication to occur.  In GDM's case
> > this is before proceeding to roll out a session for the user.
> > It could certainly say "please insert your card".  I'm not sure
> > what you mean by "click to logoff", but that sounds like
> > something you want to happen within a session, not at
> > authentication time.  PAM can't get involved after authentication
> > has completed.  You don't need to authenticate to log off anyway,
> > so I'm not sure why you'd want this.
> >
> >    
> Under windoze (and I like that feature), once you are logged in through the 
> card, if you remove that card from the reader, the sessions locks. Then your 
> options are
> 1) to insert your card again and authenticate yourself (so from the above, I 
> have a problem with PAM)
> 2) logoff or restart/shutdown the PC
>  

Once you implement your daemon above, there's no reason a
screen-locker can't subscribe to the event notification and
invoke a lock action on a card-remove event.  But this has
nothing to do with PAM or gdm.

> > > As two side questions, and assuming I've understood your meaning:
> > >
> > > 1) how does PAM handle dialogs ?
> > >      
> > When the client calls pam_start() to initialize the PAM framework,
> > it passes in a pointer to a "conversation function" that takes a
> > string for a prompt and returns a string with the response.  The
> > PAM service modules, when they want to do a user interaction, call
> > the conversation function in the client.
> >
> >    
> >
> > > 2) where is the responsibility boundary between gdm and PAM
> > >      
> > pam_authenticate() is when the client (gdm) passes control
> > to PAM.  Depending on what PAM modules you've configured in
> > pam.conf, and how you've configured them, one or more
> > modules might get control in succession.  Each does their
> > notion of "authentication", interacting with the user as
> > required, and returns PAM_SUCCESS if they are satisfied.  If
> > all the configured modules return PAM_SUCCESS, then the
> > pam_authenticate() returns PAM_SUCCESS to the client (gdm).
> > If any module returns PAM_AUTH_ERR, then that gets returned
> > to the client.  In the smartcard case, you probably expect
> > admins to only configure your smartcard PAM module.  Maybe
> > they'd also like to put a fingerprint scanner PAM module
> > onto the stack for extra security, as well as a retina-scan
> > PAM module :-).  It's up to the administrator to use one or
> > all of these methods by configuring appropriate PAM modules
> > for GDM (and any other authentication clients like screen lockers)
> > in pam.conf.
> >    
>
> I am still confused as to who handles the various dialog boxes: ex I insert a 
> card and the dialog only allows for a PIN while if I click on "By hand", I 
> can choose a user + password the usual way.
>  

Partly my fault - I realized after posting this that my
description wasn't entirely complete.  Yes, gdm calls
pam_start() and passes in a pointer to its "conversation
function" which can take a prompt and return a user
response.

It then calls pam_authenticate(), and this passes control
to the PAM framework, which finds the PAM stack for
gdm and starts invoking the modules on the stack.  Each module
has a pam_sm_authenticate() entrypoint that gets invoked,
and when it wants to do a prompt/response interaction
it looks up the pointer to gdm's conversation function
passed earlier into pam_start(), and invokes it.  This temporarily
passes control back to a part of gdm, which displays the
prompt and a text-input box, and then returns what the
user typed into the box, returning control back to PAM.
The service module retrieves the response and does
whatever authentication magic it desires with it.  It can
invoke the conversation function as many times as it likes
to get all the input it needs to authenticate.
At the end, the service module returns an error, or a
response indicating the result of the authentication - either
PAM_SUCCESS or PAM_AUTH_ERR.  Depending on the
configuration in pam.conf the PAM framework may then invoke
pam_sm_authentication() in another PAM service module.
Eventually the PAM framework returns an authentication
status to gdm.

-Bob