make depend
Unregister error message key on library unload

Revision fcdd2de1 added the K5_KEY_GSS_KRB5_ERROR_MESSAGE key, and
registered it in the gssapi library initialization routine, but
did not unregister it in the libary finalization routine.
When the library is unloaded and reloaded in the same process,
this leads to an assertion failure, since we check that
destructors_set[keynum] is zero (no destructor set) when registering
a key in util/support/threads.c.
Unregister the key on library cleanup to resolve the error.

ticket: 7353
target_version: 1.10.4
tags: pullup
Map CANTLOCK_DB to SVC_UNAVAILABLE in krb5kdc

The KDC should not return KRB5KRB_ERR_GENERIC (KRB_ERR_GENERIC) when the
KDB plugin returns KRB5_KDB_CANTLOCK_DB: it should return
KRB5KDC_ERR_SVC_UNAVAILABLE (KDC_ERR_SVC_UNAVAILABLE) instead.  This
allows clients to immediately fallback onto other KDCs.

When we switch to using blocking locks in the db2 KDB backend we'll very
rarely hit this code path, perhaps only when racing against a kdb5_util load.
Other KDB backends might still return KRB5_KDB_CANTLOCK_DB often enough that
this change is desirable.

ticket: 7358 (new)
Use blocking locks in krb5kdc and libkadm5srv

We don't really need or want to use non-blocking locks, and we certainly
don't want to sleep(1) in krb5kdc (possibly several times, as there was
a loop over this) when either of the principal or policy DB is locked.
Some callers still request non-blocking locks, and ctx_lock() still
honors this.

ticket: 7359 (new)
Fix lock inconsistency in ctx_unlock()

The lock inconsistency fixed here is quite possibly the same as
described in https://bugzilla.redhat.com/show_bug.cgi?id=586032 .

The problem is that ctx_unlock() fails to unlock the principal DB if
it fails to unlock the policy DB, and this happens when ctx_lock()
fails to lock the policy DB (likely because the caller is racing
against a kdb5_util load, which will be using a "permanent" lock,
meaning that the lock file will be unlinked after acquiring the
lock).  The fix is to perform both unlock operations *then* handle
any errors that either or both might have returned.

Additionally, we don't really need or want to use non-blocking locks,
and we certainly don't want to sleep(1) in krb5kdc (possibly several
times, as there was a loop over this) when either of the principal or
policy DB is locked.  Some callers still request non-blocking locks,
and ctx_lock() still honors this.

ticket: 7360 (new)
Test the inconsistent locking fix and svc unavail

Test the fix for https://bugzilla.redhat.com/show_bug.cgi?id=586032 .

Also test that krb5kdc can return svc unavailable
Fix typo in util/support/Makefile.in
Improve LEASHAUTOINIT description

This installer option determines whether the -autoinit argument
is passed to the MIT Kerberos executable.
On startup, if this argument is passed, and if there are no tickets
in the default cache, and if no useful tickets can be imported from
the LSA cache, MIT Kerberos will open the get ticket dialog and prompt
for a password; this option does not appear to have any other effect.

ticket: 7357 (new)
queue: kfw
target_version: 1.10.4
tags: pullup
Tidy up GSSAPI test programs

Factor out some common functions used by multiple test programs.  Use
a common argument format for importing names (p:princname,
h:hostbasedname, or u:username) and adjust the Python tests to match
it.  Use more consistent conventions in test programs and fix some
coding style issues.  Normalize how the test programs are built.
Remove osa_adb_rename_db

This function wasn't used anywhere.  Also remove the declaration for
osa_adb_close_policy(), which doesn't exist.
Avoid multiply defining OIDs in tests/gssapi

Declarations of gss_OID_desc mech_krb5, etc. in tests/gssapi/common.h
can result in multiple definitions when the test programs are linked.
Prefix the declarations with "extern" to prevent this.
Avoid leaks on gss_accept_sec_context errors

Failure handling during the postprocessing of
mech->gss_accept_sec_context was inconsistent.  In one case we delete
the output token but leave the partly-constructed context present in
*context_handle (violating RFC 2744 if this is the first call); in
other cases we leave the output token in the caller's buffer but do
destroy the partly-constructed context.  Make this more consistent by
always destroying the output token and partly-constructed context.
(RFC 2744 prefers, but does not require, leaving the
partly-constructed context present on error if it was present on
entry.  At the moment we are ignoring that preference.)

[ghudson@mit.edu: Rewrote commit message with more details]
Add tests for gss_inquire_mechs_for_name
Simplify gss_inquire_mechs_for_name

Use gss_indicate_mechs instead of gssint_get_mechanisms and
gssint_mech_to_oid to iterate over the list of mechanism OIDs.  Use a
static helper to determine whether a mech supports a name type,
avoiding most of the work done in the for loop.  Use a cleanup
handler.  Don't leave partial results in the output parameter on
error.
Delete unused internal mechglue functions

Get rid of gssint_get_mechanisms, gssint_mech_to_oid, and
gssint_oid_to_mech, which constructed a list of mechanism names and
mapped between mech names and OIDs.  These functions were only used by
gss_inquire_mechs_for_name, which now uses gss_indicate_mechs instead.
Refactor gss mech config parser

Use helper functions to shorten and clarify loadConfigFile.
Remove NSIS installs when upgrading to 64-bit

The NSIS installer appears to have only ever existed as a 32-bit
software.  As such, unconditionally check the 32-bit registry tree
for an uninstall string; the architecture of the current package
being installed is not relevant to what was previously installed.

ticket: 7362 (new)
queue: kfw
target_version: 1.10.4
tags: pullup
Resolve verifier cred in accept_sec_context

If the verifier cred handle is of type GSS_C_BOTH, we need to resolve
the initiator part of it in order to create a s4u2proxy delegated
credential handle.  (If it's of type GSS_C_ACCEPT, kg_resolve_cred
won't do anything beyond locking and validating the credential.)

ticket: 7356
Keep verifier cred locked in accept_sec_context

It might have been safe to access the krb5 verifier cred without a
lock before constrained delegation, but it is less likely to be safe
now that we might access both the initiator and acceptor parts of the
cred.  Hold a lock on the cred for the full accept_sec_context
operation.

ticket: 7366 (new)