Recent changes to bugs

#62 Fails to build with MIT Kerberos 1.18

2021-03-02T17:44:23.802000Z

I replaced the patch in ticket #61 with this instead(quite some time ago):
```
--- ./src/mod_auth_kerb.c.org 2020-08-13 17:30:15.901691505 +0200
+++ ./src/mod_auth_kerb.c 2020-08-13 17:35:00.069621299 +0200
@@ -2062,6 +2062,11 @@
static int
have_rcache_type(const char type)
{
+ / rcache "none" is always present in modern mit-krb5
+ * but krb5_rc_resolve_full() has been removed in 1.18.x
+ * so hardcode to true */
+ return 1;
+#if 0
krb5_error_code ret;
krb5_context context;
krb5_rcache id = NULL;
@@ -2079,6 +2084,7 @@
krb5_free_context(context);

return found;

+#endif
}

/***********

Fails to build with MIT Kerberos 1.18

2020-11-20T20:17:23.292000Z

If you take a look at src/mit-internals.h you'll see that the code copies internals from MIT Kerberos 1.3 to try and disable the replay cache. Unfortunately, the replay cache was refactored in ersion 1.18, and these internals no longer build. There's a "fix" to this in ticket 61, but that fix introduces a memory leak and replaces one set of internals with another. At this point I am fairly sure that the actual default replay cache should work, even against Microsoft authenticators, so we could simply remove the internals completely and use the default replay cache.
It might be better to disable things. That can be done with a setenv call, but that's undesirable in a apache module. I'm not remembering off the top of my head whether there's a better way to do this at the gss layer.

#61 Use after free in authenticate_user_krb5pwd()

2020-08-12T16:00:14.841000Z

This makes mod_auth_kerb load when built against mit-krb5-1.18.2
Not run tested yet

#61 Use after free in authenticate_user_krb5pwd()

2019-10-21T03:49:20.809000Z

FYI I've just added this patch to the Debian package of mod_auth_kerb in response to Debian bug #934043.

Use after free in authenticate_user_krb5pwd()

2018-12-13T08:59:26.371000Z

In verify_krb5_user() krb5_kt_close() is called under certain conditions, but krb5_kt_close() is also called from the top level function authenticate_user_krb5pwd() after calling verify_krb5_user().
This leads to a use after free, since kbr5_kt_close() free up memory pointed to in the keytab struct and
the next call to krb5_kt_close() will dereference pointers in that (now freed) memory.
This leads to a segmentation fault with recent versions of MIT Kerberos.

Patch to fix this attached.

#60 Strim REALM\ in username

2016-11-23T17:06:38.179000Z

Looks like this should be done somewhere in function authenticate_user_krb5pwd, where also the '@' character is searched in the auth line

Strim REALM\ in username

2016-11-23T16:59:29.590000Z

Hi,
This is quite similar to [#42]. Citrix sends the user name as "REALM\username", and mod_auth_krb then tries to authenticate the username "REALMusername".
Can this be fixed as in [#42]?
Thanks

Login fails if Password contains § Symbol

2015-06-05T10:28:25.444000Z

krb5_get_init_creds_password() failed: Invalid argument

KrbSaveCredentials + KeepAlive = poof

2013-04-01T06:29:16Z

I know my way around Apache modules, but I'm an initiate to mod_auth_kerb, and I've noticed that when I refresh my test CGI too frequently, the credential cache disappears. This doesn't happen, however, if I set KeepAlive off.

I understand that Kerberos operates at the connection level, so it seems as if it would be possible to authenticate on the first request and then keep that connection authenticated until it disconnected, at which point the credential cache could be removed. This behaviour would gracefully degrade to Connection: close.

I'd be happy to hack on it if somebody would show me around.

Crash on graceful Apache reload

2012-12-28T02:07:51Z

After upgrading to Apache 2.2.23 recently, I found that initiating a graceful reload of a running Apache process (i.e. /etc/init.d/apache2 reload) would cause Apache to crash. By turning on debug logging, I was able to find this message, indicating that the problem was caused by mod_auth_kerb:

apache2: threads.c:351: krb5int_key_register: Assertion `destructors_set[keynum] == 0' failed.
[Thu Dec 27 20:04:58 2012] [notice] seg fault or similar nasty error detected in the parent process

Please let me know if there is a way I can provide additional information in order to help you track down this problem.