Heimdal's HDB plugin interface, and hence Samba's KDC that depends upon
it, doesn't work on 32-bit builds due to structure fields being arranged
in the wrong order. This problem presents itself in the form of
segmentation faults on 32-bit systems, but goes unnoticed on 64-bit
builds thanks to extra structure padding absorbing the errant fields.
This commit reorders the HDB plugin structure fields to prevent crashes
and introduces a common macro to ensure every plugin presents a
consistent interface.
Samba BUG: https://bugzilla.samba.org/show_bug.cgi?id=15110
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Without the change the build fails as:
CC hdb-ldap.lo
hdb-ldap.c:2109:5: warning: initialization of 'unsigned char:1' from 'krb5_error_code (*)(struct krb5_context_data *, void **)' {aka 'int (*)(struct krb5_context_data *, void **)'} makes integer from pointer without a cast [-Wint-conversion]
2109 | init,
| ^~~~
hdb-ldap.c:2109:5: note: (near initialization for 'hdb_ldapi_interface.is_file_based')
hdb-ldap.c:2109:5: error: initializer element is not computable at load time
hdb-ldap.c:2109:5: note: (near initialization for 'hdb_ldapi_interface.is_file_based')
hdb-ldap.c:2110:5: warning: initialization of 'unsigned char:1' from 'void (*)(void *)' makes integer from pointer without a cast [-Wint-conversion]
2110 | fini,
| ^~~~
hdb-ldap.c:2110:5: note: (near initialization for 'hdb_ldapi_interface.can_taste')
hdb-ldap.c:2110:5: error: initializer element is not computable at load time
hdb-ldap.c:2110:5: note: (near initialization for 'hdb_ldapi_interface.can_taste')
hdb-ldap.c:2111:5: warning: initialization of 'krb5_error_code (*)(struct krb5_context_data *, void **)' {aka 'int (*)(struct krb5_context_data *, void **)'} from incompatible pointer type 'char *' [-Wincompatible-pointer-types]
2111 | "ldapi",
| ^~~~~~~
hdb-ldap.c:2111:5: note: (near initialization for 'hdb_ldapi_interface.init')
hdb-ldap.c:2112:5: warning: initialization of 'void (*)(void *)' from incompatible pointer type 'krb5_error_code (*)(struct krb5_context_data *, HDB **, const char *)' {aka 'int (*)(struct krb5_context_data *, HDB **, const char *)'} [-Wincompatible-pointer-types]
2112 | hdb_ldapi_create
| ^~~~~~~~~~~~~~~~
hdb-ldap.c:2112:5: note: (near initialization for 'hdb_ldapi_interface.fini')
hdb-ldap.c:2113:1: warning: missing initializer for field 'prefix' of 'struct hdb_method' [-Wmissing-field-initializers]
2113 | };
| ^
Started failing when commit 93ada1fbf ("hdb: Remove default HDB backend
footgun") added extra fields to 'struct hdb_method'.
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.
Do not allow a change in build configuration time default HDB backend
selection cause existing default HDBs to not be possible to open.
Otherwise such a change will cause a KDC configured to use the default
HDB (i.e., without setting it in the "database" stanza in the "[kdc]"
section of krb5.conf) to not start.
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.
Heimdal will refuse to create new entries when an entry already exists even
if said entry has no kerberos info and is a new entry.
This patch fixes this issue by allowing object modifications even if the
flags disallow them when we are inserting a new principal on the database.
Signed-off-by: Francisco Blas Izquierdo Riera (klondike) <klondike@gentoo.org>
Commit 4b6bd40106 made hdb_ldap_create and
hdb_ldapi_create static in the OPENLDAP_MODULE case. However, by
failing to leave a blank line between the static and the function
declaration the perl program that produces the hdb-protos.h file
skips the functions.
Add appropriate spacing.
Change-Id: I9ad24176fc31a0bce92b51f7adab141e8fa70fa3
In hdb_ldap_common() the test
if (search_base == NULL && search_base[0] == '\0')
error handling ...
must be
if (search_base == NULL || search_base[0] == '\0')
error handling ...
Change-Id: I8d876a9c56833431b3c4b582fbb0a8cc7353893d
We used to update the iprop log and HDB in different orders depending on
the kadm5 operation, which then led to various race conditions.
The iprop log now functions as a two-phase commit (with roll forward)
log for HDB changes. The log is auto-truncated, keeping the latest
entries that fit in a configurable maximum number of bytes (defaults to
50MB). See the log-max-size parameter description in krb5.conf(5).
The iprop log format and the protocol remain backwards-compatible with
earlier versions of Heimdal. This is NOT a flag-day; there is NO need
to update all the slaves at once with the master, though it is advisable
in general. Rolling upgrades and downgrades should work.
The sequence of updates is now (with HDB and log open and locked):
a) check that the HDB operation will succeed if attempted,
b) append to iprop log and fsync() it,
c) write to HDB (which should fsync()),
d) mark last log record committed (no fsync in this case).
Every kadm5 write operation recover transactions not yet confirmed as
committed, thus there can be at most one unconfirmed commit on a master
KDC.
Reads via kadm5_get_principal() also attempt to lock the log, and if
successful, recover unconfirmed transactions; readers must have write
access and must win any race to lock the iprop log.
The ipropd-master daemon also attempts to recover unconfirmed
transactions when idle.
The log now starts with a nop record whose payload records the offset of
the logical end of the log: the end of the last confirmed committed
transaction. This is kown as the "uber record". Its purpose is
two-fold: act as the confirmation of committed transactions, and provide
an O(1) method of finding the end of the log (i.e., without having to
traverse the entire log front to back).
Two-phase commit makes all kadm5 writes single-operation atomic
transactions (though some kadm5 operations, such as renames of
principals, and changes to principals' aliases, use multiple low-level
HDB write operations, but still all in one transaction). One can still
hold a lock on the HDB across many operations (e.g., by using the lock
command in a kadmin -l or calling kadm5_lock()) in order to push
multiple transactions in sequence, but this sequence will not be atomic
if the process or host crashes in the middle.
As before, HDB writes which do not go through the kadm5 API are excluded
from all of this, but there should be no such writes.
Lastly, the iprop-log(1) command is enhanced as follows:
- The dump, last-version, truncate, and replay sub-commands now have an
option to not lock the log. This is useful for inspecting a running
system's log file, especially on slave KDCs.
- The dump, last-version, truncate, and replay sub-commands now take an
optional iprop log file positional argument, so that they may be used
to inspect log files other than the running system's
configured/default log file.
Extensive code review and some re-writing for clarity by Viktor Dukhovni.
A careful code review was undertaken, and it was determined
that the best way to store the extended attributes was in a
native ASN1 encoded field. LDAP does not understand the
SEQUENCE of SEQUENCE structures used extensively throughout
the extended attributes structure, and there was already a
precedent set for storing the krb5Key data in a native ASN1
encoded field.
The hdb_ldap_create and hdb_ldapi_create prototypes use the "static"
keyword, but the functions themselves are not implemented as static.
Heimdal's buildsystem dynamically adds function declarations to
hdb-protos.h based on the actual function implementations. Those
declarations in hdb-protos.h are not declared as static.
Since the build system generates the declarations dynamically, just
remove them from hdb-ldap.c.
This uses a seperate hdb-ldap-secret-file configuration value, which
specifies an external file that may be used to supply the LDAP bind dn
and password. This allows that specific file to be configured with more
restrictive permissions than the global krb5.conf.
Signed-off-by: Love Hornquist Astrand <lha@h5l.org>
Commit 9f696b11c2 changed the
behaviour of key expiry for principals that have an sambaPwdLastSet
attribute in LDAP. The change was twofold:
* if "password_lifetime" is not set in kdc.conf a default lifetime
of 1 year is enforced
* krb5PasswordEnd is not honoured.
This patch causes pw_end to be modified only if sambaPwdLastSet
*and* "password_lifetime" is defined in kdc.conf.
Signed-off-by: Love Hornquist Astrand <lha@h5l.org>
A typo in LDAP__lookup_princ makes using existing LDAP entries broken,
a new entry is always created even if an entry with proper uid and
structural objectclass can be found.
Signed-off-by: Love Hornquist Astrand <lha@h5l.org>
Johan Gadsjö did a awesome analysis of the LDAP access pattens
and sent us a patch that reduced the calls the ldap server by 4
times as many. The patch was adopted and change to avoid compile
time depencies and make the determination runtime instead. Thanks!
ldap special characters, this should really be quoting instead.
git-svn-id: svn://svn.h5l.se/heimdal/trunk/heimdal@23941 ec53bebd-3082-4978-b11e-865c3cabbd6b
