Use retval, not errno, when stashing master keys

The krb5_db_store_master_key{,_list} functions return a
krb5_error_code, and do not necessarily set errno on failure.
Use the correct variable while reporting errors with com_err().
Clean up stash file error handling

The comment previously failed to match the behavior. The intent was
that if we failed to write out the entire stash file into the
temporary location, we should remove the partial file.  However, the
code was actually checking whether the *real* stash file existed,
not whether the temporary one existed.

It is safe to always try to unlink the partial file, and not worry
about whether it already exists.
Remove last uses of "possibly-insecure" mktemp(3)

Many libc implementations include notations to the linker to generate
warnings upon references to mktemp(3), due to its potential for
insecure operation.  This has been the case for quite some time,
as was noted in RT #6199.  Our usage of the function has decreased
with time, but has not yet disappeared entirely.  This commit
removes the last few instances from our tree.

kprop's credentials never need to hit the disk, so a MEMORY ccache
is sufficient (and does not need randomization).
store_master_key_list is explicitly putting keys on disk so as to
do an atomic rename of the stash file, but since the stash file
should be in a root-only directory, we can just use a fixed name
for the temporary file.  When using this fixed name, we must detect
(and error out) if the temporary file already exists; add a test to
confirm that we do so.

ticket: 1794
Avoid deprecated krb5_get_in_tkt_with_keytab

The kprop code has been pretty unloved, and uses some routines that
are marked as deprecated (which show up as warnings in the build log).
Use the documented replacement for krb5_get_in_tkt_with_keytab,
krb5_get_init_creds_keytab, instead.  As a bonus, there is no longer
a side effect of a credentials cache that needs to be destroyed.

The also-deprecated function krb5_get_in_tkt_with_skey was backending
to it when no keyblock was passed in; we can unroll the call to
krb5_get_init_creds_keytab ourselves as the documented workaround.
While here, improve style compliance with regards to cleanup.

The setkey test just wants to know whether it can use the key it
just put into a keytab to get credentials; as such the recommended
krb5_get_init_creds_keytab is quite sufficient.
While here, use that interface to request the particular enctype
as well, reducing the scope of an XXX comment.

ticket: 6366
Make set_cloexec_fd return void

We never check its return value (causing clang to emit warnings),
and its use is primarily in cases where we should continue processing
in the event of failure.  Just ignore errors from the underlying
fcntl() call (if present) and treat this operation as best-effort.

The #if 0 code should probably be removed.
Clean up the code to eliminate some clang warnings

In ure.c, though k is a short, the literal 1 is of type 'int', and
so the operation 'k + 1' is performed at the (32-bit) width of int,
and therefore the "%d" format string is correct.

In accept_sec_context.c, the 'length' field of krb5_data is an
unsigned type, so checking for a negative value has no effect.

In net-server.c, the helper routine rtm_type_name() is only used
in code that is disabled with #if 0 conditionals; make the
definition also disabled in the same way to avoid warnings of an
unused function.

In kdc_authdata.c, equality checks in double parentheses elicit
a warning from clang.  The double-parentheses idiom is normally used
to indicate that an assignment is being performed, but the value of
the assignment is also to be used as the value for the conditional.
Since assignment and equality checking differ only by a single
character, clang considers this worthy of a warning.  Since the extra
set of parentheses is redundant and against style, it is correct to
remove them.

In several places (sim_server.c, dump.c, kdb5_destroy.c,
ovsec_kadmd.c), there are declarations of extern variables relating
to getopt() functionality that are now unused in the code.  Remove
these unused variables.
Remove rtm_type_name()

It has been unused since 2009 when Ken decided that the routing log
messages were too verbose (commit 91fc077c96926dd60).
Multi-realm KDC null deref [CVE-2013-1418]

If a KDC serves multiple realms, certain requests can cause
setup_server_realm() to dereference a null pointer, crashing the KDC.

CVSSv2: AV:N/AC:M/Au:N/C:N/I:N/A:P/E:POC/RL:OF/RC:C

A related but more minor vulnerability requires authentication to
exploit, and is only present if a third-party KDC database module can
dereference a null pointer under certain conditions.

ticket: 7755 (new)
target_version: 1.12
tags: pullup
Don't try to stat() not-on-disk ccache residuals

Don't assume that ccache residual names are filenames which we can
stat() usefully.  Instead, use helper functions to call the library
routines to try to read the default principal name from caches.
Use an in-memory cache until we need the target's

Instead of copying source or obtained creds into the target cache and
changing ownership if everything succeeds, copy them into a MEMORY:
cache and then, if everything succeeds, create the target cache as the
target user.
Learn to destroy the ccache we're copying from

Add a flag to krb5_ccache_copy() which will instruct it to destroy a
source ccache after reading its contents.  Using this when we copy the
creds from a MEMORY cache to somewhere else is necessary to avoid having
a subsequent call to krb5_cc_cache_match() select the MEMORY cache when
we're trying to have it search a different location by default.
Try to use the default_ccache_name'd as the target

Try to use the location named by the default_ccache_name setting as the
target cache.  If it's a collection, just create or update a subsidiary
cache.  If it's not, then fall back to creating a new cache to try to
avoid destroying the contents of one that might already be there.  We
can't really detect this in advance for KEYRING: caches, though.
Be more careful of target ccache collections

When copying credentials to a cache collection, take care to avoid
generating multiple caches for a single client principal, but don't
change the primary out from anyone who might already be using the
target collection.
Copy config entries to the target ccache

When we try to screen out expired creds while reading them from one
ccache to eventually store in another, also keep configuration entries.