Does you pam_krb5 have a refresh_creds option? That could be used with
the xcreensaver, to reuse the cache pointed at by the KRB5CCNAME.
Russ Allbery wrote:
Derrick J Brashear <[EMAIL PROTECTED]> 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).
--
Douglas E. Engert <[EMAIL PROTECTED]>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
