Re: [gdm-list] adding a command to externaly fill the username field

[Bob Doolittle <Robert Doolittle Sun COM>]

syrius ml no-log org wrote:

> Ok, I think I see what you mean.
> Without considering the complex login (smartcard+tradionnal way) but
> only the smartcard based one:
> wouldn't it be as difficult to handle that kind of situation:
> A user enters his card, the pam library asks for the
> password/pin/whatever, the user removes his card and another user
> inserts his card after him. (before the first user has completed the
> authentication process)
> How could this kind of situation be handled by pam libraries ?
> (the password check for the 1st user has to be interrupted)
>  

This doesn't seem to me to be fundamentally different from
a traditional login issue.  Once somebody has entered their
user name, and they are at a Password prompt, if they walk
away the next person to walk up to the terminal needs to clear
the state somehow.  In dtlogin, we had a "Start Over" button
which would reset the interaction (in PAM parlance, we'd
return from the conversation function with some status that
indicates an error so we can start over).  gdm doesn't have
such a button IIRC, so we expect people to just hit return
or something to reset the interaction, right?  It would be the
same for PIN-entry I believe.  Given that you have a smartcard
framework that can deliver card-insert events, and given a
situation where you only want to handle smartcard logins,
I could imagine pam_sm_authenticate() logic like:

Block for card-entry (maybe after putting up your own popup
      window saying "Please insert card")
Tear down popup window
Read username off of unlocked portion of card
Set PAM_USER to username
Call conversation function with "Please enter PIN"
Has another card insert or card remove event occurred while
    we were blocked in the conversation function?
 Yes: return PAM_AUTH_ERROR so we can start all over in the PAM stack
 No: authenticate, and return PAM_SUCCESS or PAM_AUTH_ERROR

Maybe you don't have to detect the card insert/card remove, just
authenticate and it will fail if the card has changed (although if the card
locks up after a certain number of failed authentication passes this
is rather unfriendly since the user gets an unfair strike against them).

Also, remember that at the PIN-entry stage GDM will be displaying
"Welcome Fred, please enter PIN:".  So before George inserts his
card he might very well realize he simply needs to press return
first.  Same as the traditional password entry case, right?

>  
>
> > Before you turn away in disgust and go back to hacking
> > gdm directly - think about screensavers. Whatever auth
> > methods you want to use to login you probably also want
> > to use to unlock your screen if you've walked away for
> > a while. This is the primary value of PAM IMO. You can
> > put the same modules onto a screensaver PAM stack
> > as you do on gdm's stack.
> >    
>
> Hopefuly I only have to handle logons.
> We have a crappy proprietary solution to allow users to log on public
> windows computers with their limited smartcard (the smartcard doesn't 
> contain any private key) (it's based on a crappy gina.dll that doesn't
> even interact well with windows)
> I'm trying to find a solution to use linux instead of windows.
>
> My last thoughts were about to write a greeter that would handle my
> special needs :)
> It seems for special needs like mines, pam is not enough. And using
> pam would require more hacks than just quickly hacking a greeter.
>  

Care to elaborate?

-Bob