Re: [HACKERS] Krb5 & multiple DB connections

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> >> I have little idea of how expensive the operations called by
> >> pg_krb5_init really are. If they are expensive then it'd probably
> >> make sense to keep the current static variables but treat 'em as a
> >> one-element cache, ie, recompute if a new user name is being demanded.
> >> If not, we ought to be able to simplify some things.
>
> > We'd have to recompute based on the KRB5CCNAME environment variable
> > changing, which is certainly an option. It's not necessairly the case
> > that the username is changing, possibly just the cache.
>
> Hm, apparently I completely misunderstand the problem here. What I
> thought the bug was was that the cache wasn't recomputed given an
> attempt to connect as a different Postgres username than the first
> time. If that's not the issue, then what is?

The specific problem which I and the original reporter ran into is this:

KRB5CCACHE=/tmp/krb5cc_apache_aev0kF
pg_connect() -- works fine
pg_close() -- works fine
rm /tmp/krb5cc_apache_aev0kF
KRB5CCACHE=/tmp/krb5cc_apache_cVMRtA
pg_connect() -- Doesn't work, Kerberos error is "no credentials cache"

What's happening here is that for every connection to apache by the
client a new credentials cache is created, and then destroyed when the
connection closes. When using PHP (ie: phppgadmin) and mod_php (as is
common) the Apache process is the one actually making the connection to
the database and a given Apache process usually serves multiple requests
in its lifetime, sometimes to the same user, sometimes to different
users.

The static variables being used are for: krb5_init_context,
krb5_cc_default, krb5_cc_get_principal, and krb5_unparse_name.
Technically, between one connection and the next, krb5_cc_default,
krb5_cc_get_principal and krb5_unparse_name could reasonably return
different values. krb5_init_context is pretty unlikely to change as
that would mean /etc/krb5.conf changed. Looking through the krb5 source
code it appears that the only one which checks for something existing
is krb5_cc_default_name (called by krb5_cc_default), which will just
return the current ccache name if one has been set.
(src/lib/krb5/os/ccdefname.c:278, krb5-1.4.3)

We initially brought up this issue with the Kerberos folks actually:
http://pch.mit.edu/pipermail/kerberos/2006-February/009225.html

They pretty clearly felt that the application was responsible for
handling the cache in the event it changes. Unfortunately, it's not the
application which is talking to Kerberos but another library in this
case which doesn't expose the Kerberos API to the application in such a
way to allow the application to notify Kerberos of the cache change.

Looking through the Kerberos API again it looks like it might be
possible to use krb5_cc_set_default_name(context, NULL) to force
krb5_cc_default_name() (from krb5_cc_default()) to re-find the cache.
Finding the cache again is reasonably inexpensive. I've tried a couple
of things along these lines now but I havn't found a workable solution
which doesn't reinitialize the main Kerberos context, unfortunately.
I'll keep working on it as time allows though honestly I don't believe
it's generally terribly expensive to reinitialize the context...

Sorry it took so long to reply, running down the paths through the
various libraries takes a bit of time and I was really hoping to be able
to suggest an alternative solution using krb5_cc_set_default_name.

Thanks,

Stephen