[OpenAFS] Changes for Mosaic's AFS cell...

[Jeffrey Hutzelman]

On Thursday, April 06, 2006 12:57:58 PM -0400 Christopher Allen Wing 
<wingc@engin.umich.edu> wrote:

> Derrick:
>
>
> On Thu, 6 Apr 2006, Derrick J Brashear wrote:
>
>>> That doesn't sound quite right. Anyway, why would a pam module worth
>>> anything honor the environment it was invoked with?
>>>
>>> Mine certainly didn't.
>>
>> Right, now I remember. It cleaned the environment and used the env
>> extension  to export the new value.
>
> The confusing thing here is that PAM modules can be invoked in several
> different contexts.  The straightforward case is login authentication,
> where you would want to create a new credentials cache and reset the
> KRB5CCNAME environment variable.  For the case of the screen lock, it's
> still doing authentication but it's not starting a 'login session'.

Right.  It's not starting a new session; it's refreshing credentials.  A 
correct PAM module will not try to set up a new ccache in pam_authenticate, 
but will instead wait until there is a call to pam_session_open, or a call 
to pam_setcred with PAM_ESTABLISH_CRED.  In a correct screen locker, 
neither of those calls will happen.  Instead there will be a call to 
pam_setcred with PAM_REINITIALIZE_CRED or PAM_REFRESH_CRED, which the PAM 
module should handle by updating the user's existing ccache.


>  But
> the default behavior on some (Linux) systems is for the PAM module to
> basically do a kinit when this happens, so that the user's credentials
> get refreshed.  This is so that you can lock your screen for a week and
> get new tickets/tokens after an unlog.

Yeah, some people's PAM modules are broken.  Interestingly, I'm fairly sure 
RedHat's is not one of them.  If memory serves correctly (and I haven't 
looked at that code in a year or so), their module gets this right.


> Finally, to make things more complicated there is a third way for the PAM
> module to be invoked: from a login session where the actual
> authentication has been done by another program.  For instance, the sshd
> server with GSSAPI may authenticate the user via Kerberos on its own,
> without a password.  In this case, the PAM module needs to use the
> KRB5CCNAME environment variable to find out where the sshd server stuck
> the forwarded credentials it got from GSSAPI.  The PAM module would then
> use the forwarded credentials to do an aklog.

In this case, pam_open_session will (should) be called, but there will 
never have been a call to pam_authenticate or pam_setcred.


> You might argue that these are really 3 different modes of operation and
> they should belong in 3 different PAM modules.

But they're _not_ different modes of operation.  They're just different 
combinations of smaller building blocks defined by the PAM specification. 
All the module has to do is implement each block, and recognize that in 
certain cases it needs to pass information from one stage to the next.

-- Jeffrey T. Hutzelman (N3NHS) <jhutz+@cmu.edu>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA