[1722] in Kerberos_V5_Development
load_v4 fix
daemon@ATHENA.MIT.EDU (Mark W. Eichin)
Sun Sep 8 01:40:39 1996
To: tytso@MIT.EDU, krbcore@MIT.EDU
Cc: eichin@cygnus.com
From: eichin@kitten.gen.ma.us (Mark W. Eichin)
Date: 08 Sep 1996 01:32:38 -0400
Please consider this patch for beta7...
The bug: load_v4 will *always* use a "derived" admin database name,
regardless of what the user specified in config files. This makes it
particularly difficult to test, and potentially somewhat difficult to
use.
The analysis: kdb5_util main calls kadm5_get_config_params and stashes
the result in global_params. load_v4db copies global_params, sets the
dbname (* so it looks like the user set it! *) and clears
admin_dbname... so it gets set to a name derived from dbname, like the
function is documented to do. This is of course wrong.
The fix: just copy global_params into newparams, eliminate the call,
because the *first* call to kadm5_get_config_params explicitly sets
the dbname, admin_dbname, and admin_lockfile correctly.
I've got a set of additional changes in this area: documentation for
load_v4 and a "-s v4stashfile" option, as well as some v4
compatibility tests -- but those aren't critical, and can go in later.
Index: loadv4.c
===================================================================
RCS file: /cvs/cvsfiles/krb5/kadmin/dbutil/loadv4.c,v
retrieving revision 1.2.2.2
diff -u -r1.2.2.2 loadv4.c
--- loadv4.c 1996/09/05 22:06:16 1.2.2.2
+++ loadv4.c 1996/09/08 05:15:39
@@ -354,15 +362,6 @@
* Cons up config params for new database.
*/
newparams = global_params;
- newparams.mask &= ~(KADM5_CONFIG_ADBNAME | KADM5_CONFIG_ADB_LOCKFILE);
- newparams.dbname = dbname;
- newparams.mask |= KADM5_CONFIG_DBNAME;
- if (retval = kadm5_get_config_params(context, NULL, NULL, &newparams,
- &newparams)) {
- com_err(PROGNAME, retval, "while retrieiving configuration "
- "parameters");
- return;
- }
/*
* Always create the policy db, even if we are not loading a dump
