[OpenAFS] Changes for Mosaic's AFS cell...
Christopher Allen Wing
Thu, 6 Apr 2006 12:57:58 -0400 (EDT)
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'. 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.
On the other hand some people might consider that behavior broken and
would prefer to have a ticket/token refresh daemon running in the
background instead, with renewable tickets, etc.
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.
You might argue that these are really 3 different modes of operation and
they should belong in 3 different PAM modules. But on some Linux systems
at least this is all done by a single PAM module that figures out which of
those 3 things to do based on the situation.