[15900] in Kerberos-V5-bugs

home help back first fref pref prev next nref lref last post

[krbdev.mit.edu #8651] kinit -kt KDB: Cannot find/read stored master

daemon@ATHENA.MIT.EDU (Greg Hudson via RT)
Sat Mar 17 21:51:43 2018

Mail-followup-to: rt@krbdev.mit.edu
mail-copies-to: never
From: "Greg Hudson via RT" <rt-comment@KRBDEV-PROD-APP-1.mit.edu>
In-Reply-To: <rt-8651@krbdev.mit.edu>
Message-ID: <rt-8651-48301.1.28968776261814@krbdev.mit.edu>
To: "'AdminCc of krbdev.mit.edu Ticket #8651'":;
Date: Sat, 17 Mar 2018 21:51:16 -0400 (EDT)
Reply-To: rt-comment@KRBDEV-PROD-APP-1.mit.edu
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krb5-bugs-bounces@mit.edu

[I moderated through the first copy to krb5-bugs, but not the second 
copy, and I didn't moderate through to krbdev.  I prefer if messages 
go to just one project list, so that the follow-up conversation 
doesn't get fragmented.]

The cause of this bug is obscured by an error handling flaw in kinit 
-t KDB:.  When kinit calls kinit_kbd_init(), it destroys and 
recreates the krb5_context, but doesn't reset the global variable 
errctx which is used by extended_com_err_fn().  That can be fixed 
with the following patch:

diff --git a/src/clients/kinit/kinit.c b/src/clients/kinit/kinit.c
index a518284..3fdae28 100644
--- a/src/clients/kinit/kinit.c
+++ b/src/clients/kinit/kinit.c
@@ -718,6 +718,7 @@ k5_kinit(struct k_opts *opts, struct k5_data *k5)
 #ifndef _WIN32
         if (strncmp(opts->keytab_name, "KDB:", 4) == 0) {
             ret = kinit_kdb_init(&k5->ctx, k5->me->realm.data);
+            errctx = k5->ctx;
             if (ret) {
                 com_err(progname, ret,
                         _("while setting up KDB keytab for realm 
%s"),

Without that fix, we just have the error string for 
KRB5_KDB_CANTREAD_STORED, not the extended error message set in 
krb5_db_def_fetch_mkey().  So all we know for now is that 
krb5_db_def_fetch_mkey_keytab() didn't succeed.  It's hard to 
theorize beyond that.  kt_file.c does contain locking calls, but they 
are straightforward blocking POSIX file locks which shouldn't fail.
_______________________________________________
krb5-bugs mailing list
krb5-bugs@mit.edu
https://mailman.mit.edu/mailman/listinfo/krb5-bugs

home help back first fref pref prev next nref lref last post