From basch@alum.mit.edu Sun Mar 18 12:52:17 2018 Return-Path: Received: from mta2.srv.hcvlny.cv.net (mta2.srv.hcvlny.cv.net [167.206.4.197]) by krbdev.mit.edu (Postfix) with ESMTPS id 7E3104F3FE for ; Sun, 18 Mar 2018 12:52:17 -0400 (EDT) X-Content-Analysis: v=2.1 cv=bPfrW6KZ c=1 sm=1 tr=0 a=n+6dpZyqN8Ukwn9TnfXj7Q==:117 a=n+6dpZyqN8Ukwn9TnfXj7Q==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=v2DPQv5-lfwA:10 a=Gz7s5_CCAAAA:8 a=DX8FaR3rWDbVU5usUDgA:9 a=QEXdDO2ut3YA:10 Received: from [24.190.185.144] ([24.190.185.144:59454] helo=k9.internal.bright-prospects.com) by mta2.srv.hcvlny.cv.net (envelope-from ) (ecelerity 3.6.9.48312 r(Core:3.6.9.0)) with ESMTP id AA/93-03148-F399EAA5; Sun, 18 Mar 2018 12:52:16 -0400 Received: from [192.168.15.187] (unknown [192.168.15.187]) by k9.internal.bright-prospects.com (Postfix) with ESMTP id 989CA85CE1; Sun, 18 Mar 2018 12:52:15 -0400 (EDT) Content-Type: text/plain; charset=utf-8 MIME-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [krbdev.mit.edu #8651] kinit -kt KDB: Cannot find/read stored master key From: Richard Basch In-Reply-To: Date: Sun, 18 Mar 2018 12:52:15 -0400 CC: Richard Basch Content-Transfer-Encoding: quoted-printable Message-ID: <24A0E6CA-53A3-42C5-8238-81D7AAC1AB53@alum.mit.edu> References: To: rt-comment@KRBDEV-PROD-APP-1.mit.edu X-Mailer: Apple Mail (2.3273) RT-Send-Cc: Content-Length: 2341 I ran a tight loop and simulated the issue. In my test, the following conditions existed: - The stash file is a non-standard location (and defined in the KRB5_KDC_PROFILE config (key_stash_file). - Standard location stash file did not exist (not even as a symlink) All my test essentially did was: while true ; do rm -f /tmp/ktrace.out /tmp/strace.out KRB5_KDC_PROFILE=… KRB5_CONFIG=… KRB5_TRACE=/tmp/ktrace.out strace -f -o /tmp/strace.out kinit -kt KDB: kadmin/admin || break done The final run (after thousands of success) showed it looking for the STANDARD location stash file. > On Mar 17, 2018, at 9:51 PM, Greg Hudson via RT wrote: > > [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