KRB5 context is not updated when starting a new Apache session (using mod_auth_kerb)

[gil ran]

Hi.

I am using a Linux-From-Scratch based Linux, with OpenLdap-2.3.27,
Heimdal-0.7.2, Apache-httpd-2.2.4, mod_auth_kerb-5.3 and php-5.2.1.

I'm trying to use OpenLDAP (over Heimdal GSSAPI with KRB5) from
mod_php under Apache (using php's ldap_sasl_bind with GSSAPI as
mechanism - it calls lsap_sasl_interactive_bind_s). Apache is
configured to re-use processes for handling multiple sessions
(mpm_workers_module with MaxRequestsPerChild of 0). The first time my
code runs inside any given httpd process it works OK. After that it
always fails with credentials error, which points to non-existing
credentials file from the previous time.

After some digging I discovered that the problem is due to KRB5CCNAME
evironment variable changes. When a process is re-used by Apache, it
first invokes mob_auth_kerb which authenticates and sets KRB5CCNAME
environment variable. The problem is that GSSAPI already has an
existing KRB5 context (from the previous time) which already has
default_cc_name. KRB5 does not re-read the environment variable and
stays with incorrect credentials file name.

It looks as if GSSAPI is not designed to be invoked from process
handling multiple sessions, because it does not have either of:
1) A way to re-initialize the default credentials file if the
environment changes
2) A ways to destory underlying KRB5 context after the work is
completed by the previous session.

I have an ugly hackish solution that solves my problem:
In Heimdal's KRB5 cache.cc: krb5_cc_default_name() I've changed

<    if (context->default_cc_name == NULL)
<	    krb5_cc_set_default_name(context, NULL);

To:

>    if ((context->default_cc_name == NULL) || strcmp(context->default_cc_name, getenv("KRB5CCNAME")))
>	    krb5_cc_set_default_name(context, NULL);

Which always checks the environment variables whenever default name is required.

Another solution would be to modify mod_auth_kerb, to update GSSAPI
KRB5 context when "KRB5CCNAME" is changed. This also looks extremely
ugly to me. I didn't try to do that, but it should solve the problem.

Yet another solution is to configure Apache to kill each process after
handling 1 request. This is extremely undesirable, and will cause
other problems for me.

What would be the proper solution for this?

Thanks,
Gil Ran.