When an unsigned char is shifted << 24 bits its type will be
promoted to signed 32-bits. If the value is then assigned to
an unsigned 64-bit value sign extension will occur.
Prevent the unwanted sign extension by explicitly casting the
value to unsigned long before shifting.
Change-Id: Iabeac0f17dc3229a2dc89abe71960a8ffbf523f8
Remove hdb_entry_ex and revert to the original design of hdb_entry (except with
an additional context member in hdb_entry which is managed by the free_entry
method in HDB).
Decorate HDB_entry with context and move free_entry callback into HDB structure
itself. Requires updating hdb_free_entry() signature to include HDB parameter.
A follow-up commit will consolidate hdb_entry_ex (which has a single hdb_entry
member) into hdb_entry.
Although not required to address bad code generation in
some versions of gcc 9 and 10, a coding style that requires
explicit comparison of the result to zero before use is
both clearer and would have avoided the generation of bad
code.
This change converts all use of cmp function usage from
```
if (strcmp(a, b) || !strcmp(c, d)) ...
```
to
```
if (strcmp(a, b) != 0 || strcmp(c, d)) == 0
```
for all C library cmp functions and related:
- strcmp(), strncmp()
- strcasecmp(), strncasecmp()
- stricmp(), strnicmp()
- memcmp()
Change-Id: Ic60c15e1e3a07e4faaf10648eefe3adae2543188
Sort of. It already knew.
We have a mess where new things get sent to the server as
KRB5_TL_EXTENSION, but old things get sent to the client as whatever
appropriate KRB5_TL we have, and... we call perform_tl_data() on all TL,
but we don't remove unmodified TL on the client side, and...
Anyways. This commit is a band-aid, but it works.
This is useful for services that need not be clients. For example, an
untrusted service that need only accept authentication from clients,
but not initiate authentication to other services.
If a DB does not already exist, ipropd-slave will use the compiled
default, which is not necessarily what is desired or configured in
`[kdc]`.
This change makes `hdb_default_db()` return the first dbanme in the
`[kdc]` configuration, falling back on `HDB_DEFAULT_DB`.
Also, this adds a `--database` option to `ipropd-slave`.
tests/kdc/check-iprop.in tends to wait for a log message then it reads a
status file. Well, we shouldn't write the log message before writing
the status file then!
Running ipropd-slave on a system whose hostname's realm is not the
requested realm breaks. Since the iprop client principal should really
be in the same realm as the master, we now force it after calling
krb5_sname_to_principal().
The new [hdb] new_service_key_delay parameter should not apply to
principal entries when used as clients. Otherwise new passwords would
not take effect immediately, and that would be very confusing.
This is a large commit that adds several features:
- Revamps and moves virtual host-based service principal functionality
from kdc/ to lib/hdb/ so that it may be automatically visible to
lib/kadm5/, as well as kadmin(1)/kadmind(8) and ktutil(1).
The changes are backwards-incompatible.
- Completes support for documenting a service principal's supported
enctypes in its HDB entry independently of its long-term keys. This
will reduce HDB bloat by not requiring that service principals have
more long-term keys than they need just to document the service's
supported enctypes.
- Adds support for storing krb5.conf content in principals' HDB
entries. This may eventually be used for causing Heimdal KDC
services to reconfigure primary/secondary roles automatically by
discovering the configured primary in an HDB entry for the realm.
For now this will be used to help reduce the amount of configuration
needed by clients of an upcoming HTTP binding of the kadmin service.
the code to perform cleanup is present but an overzealous goto out
precludes it from being called. break from our for loop in event of error
and allow cleanup to take place
This is the second of two commits in a series that must be picked together.
This series of two commits moves parts of lib/krb5/ infrastructure
functionality to lib/base/, leaving behind wrappers.
Some parts of libkrb5 are entirely generic or easily made so, and could
be useful in various parts of Heimdal that are not specific to the krb5
API, such as:
- lib/gssapi/ (especially since the integration of NegoEx)
- lib/hx509/
- bx509d (which should really move out of kdc/)
For the above we need to move these bits of lib/krb5/:
- lib/krb5/config_file.c (all of it, leaving forwardings behind)
- lib/krb5/config_reg.c (all of it)
- lib/krb5/plugin.c (all of it, leaving forwardings behind)
- lib/krb5/log.c (all of it, ditto)
- lib/krb5/heim_err.et (all of it)
And because of those two, these too must also move:
- lib/krb5/expand_path.c (all of it, leaving forwardings behind)
- lib/krb5/warn.c (just the warning functions, ditto)
The changes to the moved files are mostly quite straightforward and are
best reviewed with --word-diff=color.
We're also creating a heim_context and a heim API to go with it. But
it's as thin as possible, with as little state as necessary to enable
this move. Functions for dealing with error messages use callbacks.
Moving plugin.c does have one knock-on effect on all users of the old
krb5 plugin API (which remains), which is that a global search and
replace of struct krb5_plugin_data to struct heim_plugin_data was
needed, though the layout and size of that structure doesn't change, so
the ABI doesn't either.
As well, we now build lib/vers/ and lib/com_err/ before lib/base/ so as
to be able to move lib/krb5/heim_err.et to lib/base/ so that we can make
use of HEIM_ERR_* in lib/base/, specifically in the files that moved.
Once this is all done we'll be able to use config files and plugins in
lib/hx509/, we'll be able to move bx509d out of kdc/, and so on.
Most if not all of the new functions in lib/base/ are Heimdal-private,
thus calling conventions for them are not declared.
Status:
- builds and passes CIs (Travis, Appveyor)
- ran make check-valgrind and no new leaks or other memory errors
- ready for review
HOW TO REVIEW:
$ # Review file moves:
$ git log --stat -n1 HEAD^
$
$ # Review changes to moved files using --word-diff=color
$ git log -p -b -w --word-diff=color HEAD^..HEAD \
lib/base/config_file.c \
lib/base/config_reg.c \
lib/base/expand_path.c \
lib/base/warn.c \
lib/krb5/config_file.c \
lib/krb5/config_reg.c \
lib/krb5/expand_path.c \
lib/krb5/warn.c
$
$ # Review the whole thing, possibly adding -b and/or -w, and
$ # maybe --word-diff=color:
$ git log -p origin/master..HEAD
$ git log -p -b -w origin/master..HEAD
$ git log -p -b -w --word-diff=color origin/master..HEAD
TBD (future commits):
- make lib/gssapi use the new heimbase functions
- move kx509/bx509d common code to lib/hx509/ or other approp. location
- move bx509d out of kdc/
When a slave is many diffs behind, send these in batches of up to
50, then handle other slaves.
This also implements a fast-path that makes incremental diffs faster
when the log has not rolled over.
Related code cleanup.
If a slave is slow to consume what the master sends it, the master can
block and all iprop operations with it.
With minimal effort we make the master async oriented.
ipropd-master sends AYT messages often as a result of a possibly-
transient error, but if the slave responds to such an AYT with I_HAVE,
then the same code path that failed will be executed on the master, and
if the error wasn't transient then we'll loop hard. So don't send an
I_HAVE in response to an AYT.
When the master sees a burst of updates (perhaps sustained), the
slaves "I_HAVE" messages can fall behind the version we've already
sent, and the unpatched code would retransmit already sent diffs!
This can result in substantial amplification (in a local test, 3000
ops turned into 427,000 ops). Though the number of *messages* sent
was actually somewhat smaller, the ever growing message size
ultimately leads to failure.
chpass_principal_with_key_hook_cb added by 57c25d9828 must be
KRB5_LIB_CALL for 32-bit Windows builds.
Change-Id: Ifd61caeee76f9d048bb13f93e226b99ce7e8b75c
On 32-bit Windows Intel builds the __cdecl and __stdcall calling
conventions are different so labeling the functions that are
exported or assigned to function pointers matters.
Change-Id: I03b6f34baeb9ffb2e683fd979f12f27a5078a4da
Add a hook for changing a password with a key. This hook should be consolidated
into one shared with randkey and setkey, but for now I have continued to have
the hooks follow the kadm5 APIs themselves in both signature and quantity.
(This means the randkey one isn't actually very useful because it doesn't
provide the hook with the keys.)
