Russ Allbery <[EMAIL PROTECTED]> writes:
> I'm going to try a few things and see if I can get the intrusive code to
> work. I think it's currently a bit too complicated and there's a
> simpler way to get the results that it's going for.
Okay, the first problem is that the definition of krb5_rc_ops has changed
in 1.4.3 to add an additional callback. That's easily fixable. However,
this is a serious problem:
/* Definitions from MIT krb5-1.3.3 gssapiP_krb5.h */
typedef struct _krb5_gss_cred_id_rec {
/* name/type of credential */
gss_cred_usage_t usage;
krb5_principal princ; /* this is not interned as a gss_name_t */
int prerfc_mech;
int rfc_mech;
/* keytab (accept) data */
krb5_keytab keytab;
krb5_rcache_internal rcache;
/* ccache (init) data */
krb5_ccache ccache;
krb5_timestamp tgt_expire;
krb5_enctype *req_enctypes; /* limit negotiated enctypes to this list */
} krb5_gss_cred_id_rec, *krb5_gss_cred_id_t;
1.4.3 adds a k5_mutex_t variable as the *first* element of this struct.
The size of a k5_mutex_t appears to depend on a large set of the contents
of k5-thread.h, which depends on a ton of platform-specific discovery from
Autoconf. Duplicating all of that looks extremely unappealing.
This struct definition is currently necessary in order to find the rcache
member and replace its pointer. Right now, it replaces it with a custom
constructed krb5_rc_ops struct that replaces the store function with a
no-op; with 1.4.3, it could just use krb5_rc_none_ops. But that doesn't
help if we can't get into the bowels of GSSAPI to replace it.
I don't see a good solution down the path of selectively fiddling with
krb5 internals. It looks to me like the environment variable, as ugly as
that might be, may be the best solution for right now.
I've confirmed that setting KRB5RCACHETYPE to none and disabling the
current code hack does fix the problem, and interestingly doesn't appear
to pass the environment variable on to CGI child processes. So there is
that at least. It will affect all other uses of Kerberos in Apache,
though, most likely.
Regardless, a new libapache-mod-auth-kerb package will be needed when we
push 1.4.3 into unstable, and the 1.4.3 package should probably conflict
with the existing mod-auth-kerb packages since they rely on internal
library details that have significantly changed.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
