When reading configuration file, keep an extra copy of
the encryption types, and use this when resetting the
encryption types to default.
GSSAPI always resets the enctypes to default before obtaining
a TGS, because the enctypes might have previously altered,
so this prevents changing the etypes from the configured ones
to the full set of supported etypes.
Signed-off-by: Uri Simchoni <uri@samba.org>
Some portions of libhcrypto are reused by other projects in
diverse environments, including within operating system kernel modules.
In some such build environments, hardening measures such as grsecurity
can (randomly) reorder structure elements, so as to make it harder
for an attacker to determine the offset from a known field's address
to a different field that is needed for an attack.
However, doing so requires the use of C99 designated initializers
to make the source code compatible with such structure rearrangement,
as opposed to the "traditional" C aggregate type initializers, which
just list fields in order. This feature is also available as a
GCC extension since early versions of GCC. However, it is not
provided by many common versions of visual studio (and presumably
also not by the vendor compiler for various commercial Unixes),
so the traditional initializers must remain, behind a conditional.
__GNUC__ or __STDC_VERSION__ >= 199901 should be enough to get
most cases with support for designated initializers, at least
for now.
Signed-off-by: Nicolas Williams <nico@twosigma.com>
Newer versions of SQLite3 have a number of new features that are
desirable to users who host other DBs in the same file as the HDB (for
example), as well as performance and bug fixes.
We should consider switching the SQLite3 backend for HDB to WITHOUT
ROWID tables for performance reasons. We should also consider using
foreign keys instead of triggers. Making any such changes requires care
to permit both, upgrade and downgrade.
We might want to use the SQLite3 session extension for a SQLite3-
specific, low-level replication (iprop). Given conflict resultion code,
or a sufficiently normalized schema, the session extension would make it
easy to create a multi-master replication system, not unlike what one
would expect of an LDAP setup, though with none of the atomicity that
LDAP is supposed to provide (specifically, O_EXCL semantics for creates
and predicates for updates) unless we were to add a locking protocol.
Note that as of 3.14, the session extension is mutually exclusive of
WITHOUT ROWID tables.
On a low update rate master, if we don't update old_version after
processing a poll timeout, we will generate spurious warnings about
missed (change) signals every time the timer expires, and will
needlessly contact the slaves.
Also implement KDC hierarchical transit policy checks. The "hier_capaths"
parameter defaults to "yes" in [libdefaults] or can be set explicitly in
[realms] per-realm.
Commit efed5633 (r24759) prefixed some symbols with rk_, but
introduced 6 duplicate symbols in the version script (because the
rk_-prefixed versions of the symbols were already present).
When the master's log does not contain the complete history, slaves
that bootstrap from scratch encountered a loop, because the master
falsely assumed a race with log truncation.
The HDB_F_ALL_KVNOS flag is not getting set in _kdc_db_fetch() if
kvno_ptr == NULL. Fix the conditional to ensure that one of
HDB_F_ALL_KVNOS or HDB_F_KVNO_SPECIFIED is set in the flags field.
Prior to this change cross-realm TGS_REQ failed with KRB5_GENERIC_ERROR
and e-text "encryption key has bad length". With this change, the
cross-realm TGS_REQ succeeds.
Change-Id: I4216137a192032544dfbdada12b5c377603ca4b6
The function, found in lib/krb5/mit_glue.c, is currently using
krb5_generate_random_keyblock(). This compiles because warning-level is
not high enough, but does not work. At runtime the
krb5_generate_random_keyblock() interprets the second argument as the
krb5_enctype (rather than a length of anything) and tries to verify it.
When the length does not match any known enctype, as usually happens, the
function fails and returns an error. If the length happened to correspond
to an enctype, the function would likely crash due to misinterpreting its
third argument as a valid krb5_keyblock.
The change uses krb5_generate_random_block() instead. This function does
not return anything -- upon detecting failure it will cause the entire
application to exist instead...
Change-Id: I865a360037a513ce91abc7abba1dc554f844b464
Follow Apple's lead and do not fail krb5_set_config_files() simply
because one of the files in the profile list fails to parse correctly.
Doing so can lead to hard to find failures and could lead to an end
user shooting themselves in the foot and no longer be able to login
to their system to fix it.
Parse as many of the files as we can. Only fail krb5_set_config_files()
if init_context_from_config_file() fails.
Change-Id: I122664c6d707a5f926643808ba414bf4f681f8b8
When flushing the uber record, retain the current log version. When the
uber record is the only (thus last) record in the log, return its nominal
version as the last version, not 0. Upgrade the log if the current uber
record version number is not 0.
Otherwise we risk storing a name with the referral (empty) realm name,
which will then cause various knock-on effects, such as thinking that
the start_realm is "", and failing to find matching credentials in the
ccache.
When storing credentials whose ticket principal is not equal to the
requested principal, store the ticket under both names not only when
the original realm is the referral realm, but more generally for any
difference at all. This matches MIT behaviour.
Allow explicit name_canon rules to specify a realm to go with the
canonicalized hostname, if that realm is empty the effect is the
same "use-referrals"
Also fix segfault when no creds and debugging
At least one "windc" plugin provided by OS X lacks a client_access()
entry point and caused the KDC to crash. The KDC now checks for each
entry point in "windc" plugins and either falls back on alternative
default functionality or fails more gracefully than by crashing.
On OS X anyways, since Heimdal cannot be built to replace the system
Kerberos implementation in OS X (even though it's based on Heimdal).
Heimdal plugins other than the CCAPI plugins have private ABIs with
strong coupling to the internals of the Heimdal libraries, thus using
system plugins in a non-system Heimdal is likely to end in tears (e.g.,
segfaults).
This means, for example, that OS X's plugins for PAC creation and
verification cannot be used by Heimdal.
When the master's log has all entries from version 1 to now, and no
uber entry (legacy master), then new slaves will not pull version 1,
because their uber record has version 1.
The fix is to force the uber version to 0 always, and avoid adding a
truncate nop when doing a full prop. The uber record now records the
database version even in the absence of any other log entries so that
we know what to pull going forward.
Prior change 83011252d7 which fixed
cross-realm trusts from AD to Heimdal removed the assignment of
'*kvno_ptr' to 'kvno' in the case where a non-zero key version
number is supplied by the caller. This breaks cross-realm trusts
from Heimdal to another realm.
This change restores the missing assignment.
Change-Id: Ic041d9d797ba4c8c0c567da55066ba5d3d1874bb
