* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > 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"
>
> And why exactly is the application trying to munge the cache like that?
> (I assume there is some state change you're not bothering to mention,
> or there would be no need for a new cache, no?)
Thought I mentioned it further down- each new Apache TCP connection gets
a new ccache file because it goes through the Negotiate protocol again
and gets a new TGT on the web server.
It works the exact same way as SSH, really. When you connect to a
remote server using SSH it will store the TGT (assuming you have
delegate_credentials enabled) in a random file in /tmp. It's not an
issue with SSH though because you don't tend to have applications which
continue running across multiple SSH sessions and which use the TGT to
reconnect to other services multiple times.
Actually, thinking about this a minute longer, it can happen w/
SSH/screen and psql. Here's an example:
----------------------
sfrost@snowman:/data/sfrost/postgres/testinstall.krb5> kinit
Password for sfrost@SNOWMAN.NET:
sfrost@snowman:/data/sfrost/postgres/testinstall.krb5> ssh snowman
sfrost@snowman:/home/sfrost> screen
sfrost@snowman:/home/sfrost> psql -d template1 -h snowman
Welcome to psql 8.1.2, the PostgreSQL interactive terminal.
[...]
Disconnect from screen, log out, reconnect, reconnect to screen
[...]
template1=> \connect template1
pg_krb5_init: krb5_cc_get_principal: No credentials cache found
----------------------
There's not really a solution to this issue (besides exit psql, reset
the environment variable, and restart psql) unless we allow the ccache
to be set in psql and then be propogated down to libpq. I actually
hacked up some .profile/.logout scripts to avoid this problem by forcing
the cache to a fixed known-spot under my home directory. I don't think
that really works for this though because everything is running as one
uid under Apache and having a fixed long-term filename would present
some additional security issues.
> It sure seems like somebody is solving the wrong problem, and doing it
> with a sledgehammer...
The sledgehammer approach would be to require people to run everything
as CGIs. This does work, of course, but is rather painful on a number
of levels...
Thanks,
Stephen
