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

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Greg Hudson via RT-2
[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
[hidden email]
https://mailman.mit.edu/mailman/listinfo/krb5-bugs
Reply | Threaded
Open this post in threaded view
|

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

Greg Hudson via RT-2
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 <[hidden email]> 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
> [hidden email]
> https://mailman.mit.edu/mailman/listinfo/krb5-bugs


_______________________________________________
krb5-bugs mailing list
[hidden email]
https://mailman.mit.edu/mailman/listinfo/krb5-bugs