Re: [gdm-list] My questions

[Bob Doolittle <Robert Doolittle Sun COM>]

Philippe C. Martin wrote:

> Hi Bob,
>
> As I said I'm a newbit here, so help me translate.
>
> quotes from another mail:
>  
>
> > 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.
> >    
> You are saying that PAM currently _can_ handle hardware events: these event 
> might not have identifiers yet, but the architecture is there to handle them.
>  

PAM is software.  To the extent that software can "handle"
hardware events, yes :-)

For any type of hardware, such as smartcards, you need
(or should have, at least) a framework/API to talk to it that
expresses a useful model abstraction for talking to the
hardware.  In the case of smartcards, you have MUSCLE.
There's no reason that PAM can't use MUSCLE to talk to
smartcards, or libusb to talk to USB devices, or specific
hardware drivers for random devices, or whatever...

> On Tuesday 04 October 2005 08:36 pm, Bob Doolittle wrote:
>  
>
> > One final note.  One of the really nice byproducts of doing
> > smartcard authentication in a PAM module is that you can
> > not only affect gdm, but screen lockers as well.  It would
> > be pretty sad if we fixed up gdm to allow you to login with
> > a smartcard, but once your screen got locked you had to
> > type in a password to unlock it.  By doing this in a PAM module,
> > and placing that PAM module on both gdm and the screen-locker's
> > stack, smartcard-insertion suddenly works for login as well
> > as screen unlock.
> >
> >    
> So PAM could "take over" some of gdm's jobs by handle the "please insert your 
> card or click on logoff " ?
>  

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.

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

-Bob

> Regards,
>
> Philippe
>
>
>
>
>
>
>
>
>
>
>  
>
> > -Bob
> >
> > Martin Paljak wrote:
> >    
> >
> > > On Tue, Oct 04, 2005 at 01:25:11PM -0700, Bob Doolittle wrote:
> > >      
> > >
> > > > 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.
> > > >        
> > > As I said it was possible that i am wrong. Last time when i worked on this
> > > issue it was 2002 i think.. Then i was left with the impression that it
> > > was not easy/possible to achive the kind of functionality i hoped for.
> > > Maybe i did not dig too deep though or it was just a sad combination of
> > > software stacked up so that it did not work so.
> > >
> > > I'll STFW/RTFM a bit more on the topic.
> > >
> > >      
> > >
> > > > 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.
> > > >        
> > > I guess at that time i even didn't work with GDM but pure login
> > > services...
> > >
> > >
> > > peace,
> > > m.
> > >      
> > _______________________________________________
> > gdm-list mailing list
> > gdm-list gnome org
> > http://mail.gnome.org/mailman/listinfo/gdm-list
> >    
>
>