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

[Russ Allbery]

Derrick J Brashear <shadow@dementia.org> writes:
> On Thu, 6 Apr 2006, Rodney M Dyer wrote:

>> On Linux the xscreensaver runs as the user but appears to be started by
>> init.  When the screen is locked, then unlocked, the PAM module
>> generates a new Kerberos 5 ticket, but doesn't use the correct ticket
>> cache.  It seems to always create a new ticket cache.  Curious as to
>> why this was happening, we killed xscreensaver and set the KRB5CCNAME
>> variable, then restarted xscreensaver thinking it would then use the
>> correct KRB5CCNAME, but again, it generated a new ticket cache.  At
>> this point xlock and screensaver is just broken.  Note:  I'm a Windows
>> guy, so I'm getting all this from our Linux sysadmin.

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

xscreensaver is running as a subprocess and can't change the environment
of the rest of your programs, so picking a new KRB5CCNAME just means that
it strands the ticket cache somewhere nothing is looking at it.  Exporting
the variable via PAM's environment extensions doesn't help since the
environment is still only inherited by child processes.

When invoked in refresh creds mode (and only then), a Kerberos PAM module
needs to honor the existing KRB5CCNAME setting and reinitialize the ticket
cache the user already has.

This is something that a lot of PAM modules appear to get wrong.
libpam-krb5 in Debian should work correctly (and does for me with
xscreensaver, but I invoke it via my own .xsession, so I don't know for
sure if it will still work correctly if invoked via X startup scripts
through xdm or the like).

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>