[29453] in Kerberos
Re: More fun with Russ' pam_krb5
daemon@ATHENA.MIT.EDU (Russ Allbery)
Tue Mar 11 20:47:16 2008
To: kerberos@mit.edu
In-Reply-To: <Pine.GSO.4.61.0803112027100.1185@supergrover.coyhile.com> (Coy
Hile's message of "Tue\, 11 Mar 2008 20\:35\:00 -0400 \(EDT\)")
From: Russ Allbery <rra@stanford.edu>
Date: Tue, 11 Mar 2008 17:46:22 -0700
Message-ID: <87iqzskbvl.fsf@windlord.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
Coy Hile <coy.hile@coyhile.com> writes:
> I note that the ticket cache is set up as I would expect it given my
> entries in pam.conf. In xscreensaver, however, the plot thickens. I've
> got the following in pam.conf for xscreensaver:
>
> |xscreensaver auth requisite pam_authtok_get.so.1
> |xscreensaver auth required pam_dhkeys.so.1
> |xscreensaver auth optional /krb5/lib/security/pam_krb5.so use_first_pass debug ccache=/tmp/krb5cc_%u_XXXXXX
> |xscreensaver auth required /krb5/lib/security/pam_afs_session.so debug
> |xscreensaver auth optional pam_unix_auth.so.1
The ccache argument will be completely ignored for the xscreensaver case
since you're refreshing an existing ticket cache. pam_krb5 will therefore
look for the existing ticket cache in KRB5CCNAME in the environment, and
if not found, will use the default library ticket cache.
I could change this behavior, but your setting above still wouldn't work.
If that ccache were honored, it would generate a new random string for
XXXXXX and hence you'd get a new ticket cache that nothing pointed at and
which you weren't actually using.
If you track down why KRB5CCNAME isn't being set properly to point to your
current ticket cache before spawning xscreensaver, that will fix the rest
of the problem, I think.
--
Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
