Continuing with websites.

I need to install the apache connector to forward servlet calls to Tomcat.

Also enabled ssl.

Did this:

sudo apt-get install libapache2-mod-jk
sudo a2enmod ssl
sudo a2enmod rewrite
sudo a2enmod dav dav_fs

Copied SSL certificates from sol to /etc/apache2/ssl.key and /etc/apache2/ssl.crt.
Copied Certificate Authority and other certs from sol's /etc/mail/certs to newly created directory /etc/certs on cumulus.

To install subversion, and the webdav connection to subversion, I did this:

sudo apt-get install subversion libapache2-svn

Copied my svn repository from sol:/usr/local/src/svn to same dir on cumulus.

Hm, svn doesn't seem to work quite yet. Or at least something is strange about the virtual web hosts...

I'm now debugging a problem where Subversion (the Subclipse Eclipse Subversion extension) gets a PROPFILE request failed on '/' because the Appache httpd server crashes in the mod_auth_kerb authentication.

Relevant versions are : Apache 2.0.54, Heimdal 0.8.1, a hacked mod_auth_kerb 5.3, eclipse 3.2.2 and Subversion JavaHL Win32 Binaries 1.2.0 for the Eclipse plugin.

A core dump examination shows that the Heimdal GSSAPI library crashes in _gss_spnego_display_name (spnego/context_stubs.c:313) because input_name is NULL, and it tries to do a name->mech and gets a segmentation fault.

Looking at the input_name that is passed to gss_display_name gives:

(gdb) print *((struct _gss_name *) input_name)
$8 = {gn_type = {length = 0, elements = 0x84a8a00}, gn_value = {
length = 139102728, value = 0x0}, gn_mn = {slh_first = 0x75}}

This name is passed from from mod_auth_kerb, authenticate_user_gss:
major_status = gss_display_name(&minor_status, client_name, &output_token, NULL);

It in turn came from gss_accept_sec_context.

Debugging (gdb /usr/sbin/httpd, run -X), break in gss_accept_sec_context:
*src_name = GSS_C_NO_NAME

I'm tracing through to see where it gets set. Currently in:
_gss_spnego_accept_sec_context
In spnego/accept_sec_context.c:1025, *src_name is set to GSS_C_NO_NAME=NULL.
Line 1041, acceptor_start called.
gss_decapsulate_token - looks like len == 0 in gdb, but doesn't return

Trace:

acceptor_start (spnego/accept_sec_context:578) calls gss_decapsulate_token
gss_decapsulate_token (mech/gss_decapsulate_token.c:50) calls der_get_oid


Weird: second parameter to gss_decapsulate_token in spnego/accept_sec_context:578 is GSS_SPNEGO_MECHANISM, which is paramter oid. Has length 6. Returns a heim_oid with:
length=7, components[] = {1, 3, 6, 1, 5, 5, 2}, size=6

gss_decapsulate_token, line 54 calls decode_GSSAPIContextToken.
Then goes into the if (der_heim_oid_cmp(&ct.thisMech, &o) == 0)

Back in acceptor_start, calls der_match_tag_and_length, then decode_NegTokenInit.
Line 628 calls select_mech.

Goes into the "Translate broken MS Kerberos OID"? Does ret = gss_duplicate_oid(minor_status, &_gss_spnego_mskrb_mechanism_oid_desc, mech_p)? or gss_duplicate_oid(minor_status, &mech->gm_mech_oid, mech_p);?
select_mech returns 0.

Think mech_cred is set to acceptor_cred->negotiated_cred_id, but unsure.
acceptor_start calls gss_accept_sec_context (recursively).
Line 222 calls m->gm_accept_sec_context (=_gsskrb5_accept_sec_context), returns major_status 851968. Calls _gss_mg_error. Calls m->gm_display_status (=_gsskrb5_display_status).

Line 196, buf=" Miscellaneous failure (see text)"
"Decrypt integrity check failed"

Line 713: sets preferred_mech_type despite all failed?

Returns ret(1) on line 772.

Back at first gss_accept_sec_context, line 233.

New name made at line 246:
print *name
$115 = {gn_type = {length = 0, elements = 0x0}, gn_value = {length = 0,
value = 0x0}, gn_mn = {slh_first = 0x84a9638}}
Line 289, returns status 1.

Blows on line 313 of _gss_spnego_display_name ( spnego/context_stubs.c:313) because name is NULL. Called from:
#0 _gss_spnego_display_name (minor_status=0xbfad6f1c, input_name=0x0,
output_name_buffer=0xd0000, output_name_type=0xd0000)
at spnego/context_stubs.c:313
#1 0xb6fdaa01 in gss_display_name (minor_status=0xbfad6f1c,
input_name=0x84a9638, output_name_buffer=0xbfad6f28, output_name_type=0x0)
at mech/gss_display_name.c:67
#2 0xb7367f55 in authenticate_user_gss (r=0x84a6130, conf=0x8230930,
auth_line=0x84a7625 "", negotiate_ret_value=0xbfad7478)
at src/mod_auth_kerb.c:1437
#3 0xb7368834 in kerb_authenticate_user (r=0x84a6130)
at src/mod_auth_kerb.c:1614
#4 0x0809b145 in ap_run_check_user_id (r=0x84a6130) at request.c:69





acceptor_start, line 664: Call on line 653 failed.
Gets to line 698

I'd like to get Apache 2 to access files on my AFS file system. Ideally both when no user is authenticated, and with user's credentials when a user has authenticated via Kerberos 5.

I have authentication via Kerberos 5 working with the auth_kerb_module (mod_auth_kerb.so).

I can't quite wrap my head around how ticket caches and afs PAGs (Process Authentication Groups) work.

Here's a writeup on PAGs and web server authentication.

Questions: How are PAGs related to the actual credentials? By the KRB5CCNAME environment variable? (I'm running the Heimdal Kerberos implementation).

Ideally the auth_kerb_module could for each access make sure the apache process/thread has tokens/PAG for either the authenticated user or the www kerberos/afs user.

In theory the mod would do k_hasafs to intialize library, k_setpag() to create a new (empty) PAG, get the proper kerberos 5 credentials (either for the user or Apache's srvtab), convert them to afs tickets with krb5_afslog, perform the request, and then after the request destroy the pag with k_unlog.

More to come (I hope)...