[2088] in Kerberos-V5-bugs
Bug in handling AFS3 salts in the KDC (V5 beta 6)
daemon@ATHENA.MIT.EDU (Ken Hornstein)
Tue Jul 9 23:22:54 1996
To: krb5-bugs@MIT.EDU
Date: Tue, 09 Jul 1996 23:22:43 -0400
From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
I'm testing out migrating our AFS database over to K5, and I discover that
even though the database has room for the AFS salt data and that the
conversion program I've written stores the realm in there, the KDC just
picks the local realm and sends that as the salt.
I saw the comment in the source about specifying a flag in the config file
down the road, but it makes more sense to me to _use_ the info out of the
database if it's available. This would make it possible to merge multiple
AFS realms into one Kerberos V realm (which may not ever happen, but it
would be nice to have the possibility).
Anyway, the following patch implements this. Note that if there isn't any
info in the database, it punts and uses the default realm. I figure this
seemed like the right thing to do.
Feedback on this is welcome.
--Ken
--- kdc_util.c.orig Tue Jul 9 23:13:01 1996
+++ kdc_util.c Tue Jul 9 22:52:36 1996
@@ -1355,9 +1355,15 @@
return retval;
break;
case KRB5_KDB_SALTTYPE_AFS3:
- /* send the same salt as with onlyrealm - but with no type info,
- we just hope they figure it out on the other end. */
- /* fall through to onlyrealm: */
+ /* If there is info stored in the salt data, then let's use that
+ (might be useful for people who want to migrate their AFS
+ database to other realms). Otherwise, fall through to onlyrealm */
+ if (client_key->key_data_length[1] > 0) {
+ if ((salt->data = malloc(salt->length)) == NULL)
+ return ENOMEM;
+ memcpy(salt->data, client_key->key_data_contents[1], salt->length);
+ break;
+ }
case KRB5_KDB_SALTTYPE_ONLYREALM:
realm = krb5_princ_realm(context, client);
salt->length = realm->length;
--- kdc_preauth.c.orig Tue Jul 9 23:16:14 1996
+++ kdc_preauth.c Tue Jul 9 23:09:59 1996
@@ -536,14 +536,26 @@
variable that specifies the old cell name. */
padata->pa_type = KRB5_PADATA_AFS3_SALT;
/* it would be just like ONLYREALM, but we need to pass the 0 */
- scratch = krb5_princ_realm(kdc_context, request->client);
- if ((padata->contents = malloc(scratch->length+1)) == NULL) {
- retval = ENOMEM;
- goto cleanup;
+ /* Use the info in the DB if it's there! */
+ if (client_key->key_data_length[1] > 0) {
+ if ((padata->contents = malloc(client_key->key_data_length[1]+1))
+ == NULL) {
+ retval = ENOMEM;
+ goto cleanup;
+ }
+ memcpy(padata->contents, client_key->key_data_contents[1],
+ client_key->key_data_length[1]);
+ padata->length = client_key->key_data_length[1]+1;
+ padata->contents[client_key->key_data_length[1]] = 0;
+ } else {
+ if ((padata->contents = malloc(scratch->length+1)) == NULL) {
+ retval = ENOMEM;
+ goto cleanup;
+ }
+ memcpy(padata->contents, scratch->data, scratch->length);
+ padata->length = scratch->length+1;
+ padata->contents[scratch->length] = 0;
}
- memcpy(padata->contents, scratch->data, scratch->length);
- padata->length = scratch->length+1;
- padata->contents[scratch->length] = 0;
break;
case KRB5_KDB_SALTTYPE_ONLYREALM:
scratch = krb5_princ_realm(kdc_context, request->client);
