So, I've been overhauling the infrastructure at the ol' hosting coop, and decided: hey, we're acquiring afs tokens using mod_waklog and a $user/daemon kerberos principle, why not use that same principle for authenticating against postgresql? Bonus features: using a user map, the user's primary principle would authenticate as the same database user, and it eliminates another indirection in the auth process (we're using identd now, probably a terrible idea).
And then reality: mod_waklog grabs tokens, but the tickets used to acquire those tokens are not available to any CGI processes. This is correct behavior afaict: being an apache equivalent to aklog, it has no business dealing with kerberos keys. So, mod_auth_kerb is probably the piece responsible for this, right? Maybe. mod_waklog has two modes for acquiring tokens: one wherein you specify the principle and a keytab for a specific location, and another where it will use any tickets previously acquired by another module. So you can grab tokens using mod_auth_kerb for real users entering passwords or forwarding tickets.
In a moment of insanity I though modify suexec might be a good idea. It was, luckily, just a moment of insanity.
So now I'm left wondering if there's even a solution. Since we're offering generic Internet hosting, requiring that members figure out authentication with kerberos in their cgi programs just to access postgresql (and one day mysql, if it can even use gssapi) isn't going to fly. If there is a solution: where oh where does it belong.
My current thinking is that I should add something like Krb5AcquireTickets $principle $keytab (or Krb5LocationPrinciple, or
I'm probably doomed. The life of a volunteer sysadmin!