We have a check for symlinks and hardlinks so that we refuse to open
ccaches through symlinks or which have hardlinks. This check is too
strict, checking for `st_nlink != 1`, which runs into trouble when a
ccache is mounted as a file into a container, in which case `stat(2)`
reports it as having zero links.
The fix is to check for `st_nlink > 1`:
- if (sb2.st_nlink != 1) {
+ if (sb2.st_nlink > 1) {
krb5_set_error_message(context, EPERM, N_("Refuses to open hardlinks for caches FILE:%s", ""), filename);
Though I question the utility of the hardlink check. MIT Kerberos
doesn't have it.
This has no real effect, but make things more clear
and matches the pattern for krb5_sendto_context().
Signed-off-by: Stefan Metzmacher <metze@samba.org>
This matches krb5_init_creds_step() from MIT. The only
difference is the type 'krb5_realm' (Heimdal) vs. 'krb5_data' (MIT).
krb5_error_code KRB5_CALLCONV
krb5_init_creds_step(krb5_context context,
krb5_init_creds_context ctx,
krb5_data *in,
krb5_data *out,
krb5_data *realm,
unsigned int *flags);
NOTE: commit 1cdc9d5f3c
"krb5: export krb5_init_creds_step()" exported
krb5_init_creds_step() the first time, but that's
not in any released version, so it should be fine
to fix up the prototype in order to make the
function actually useful for external callers.
Signed-off-by: Stefan Metzmacher <metze@samba.org>
It should not return pointers to the internal state,
this matches the way the krb5_init_creds_step() works in MIT.
NOTE: commit 1cdc9d5f3c
"krb5: export krb5_init_creds_step()" exported
krb5_init_creds_step() the first time, but that's
not in any released version, so it should be fine
to change the behavior as there can't be any
external users of the function.
Signed-off-by: Stefan Metzmacher <metze@samba.org>
_krb5_fast_anon_pkinit_step() should not set
KRB5_INIT_CREDS_STEP_FLAG_CONTINUE if it doesn't generate any output.
And krb5_init_creds_step() needs to return if
_krb5_fast_anon_pkinit_step() returned with
KRB5_INIT_CREDS_STEP_FLAG_CONTINUE set.
As that means the recursive call to krb5_init_creds_step()
generated output that should be send to a KDC and the
KDC response if needed as input for the next step.
Signed-off-by: Stefan Metzmacher <metze@samba.org>
The current prototype of krb5_init_creds_step() is completely
useless as the caller has no way to know the destination
realm for the out blob.
The only internal caller of krb5_init_creds_step()
passes hostinfo=NULL and this commit makes it more obvious that hostinfo
is always NULL.
NOTE: commit 1cdc9d5f3c
"krb5: export krb5_init_creds_step()" exported
krb5_init_creds_step() the first time, but that's
not in any released version, so it should be fine
to fix up the prototype.
The aim is to remove hostinfo from the krb5_init_creds_step() internals
completely and move krb5_init_creds_step() to a useful prototype
where it returns the destination realm for the out packet.
Which means the prototype will mostly match the one MIT is using:
krb5_error_code KRB5_CALLCONV
krb5_init_creds_step(krb5_context context,
krb5_init_creds_context ctx,
krb5_data *in,
krb5_data *out,
krb5_data *realm,
unsigned int *flags);
Follow up patches demonstrate that the hostinfo related code
in pk_verify_host() is actually dead code as all layers
just passed down the NULL value from krb5_init_creds_get().
Signed-off-by: Stefan Metzmacher <metze@samba.org>
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>
We can't rely on having every KDC support FAST and should still
support S4U2Self against such a KDC.
We also have the order of the PA-DATA elements "corrected",
KRB5_PADATA_TGS_REQ followed by KRB5_PADATA_FX_FAST and
finally KRB5_PADATA_FOR_USER. While the inner PA-DATA
only contains KRB5_PADATA_FOR_USER.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15002
Signed-off-by: Stefan Metzmacher <metze@samba.org>
As described by the C standard, __func__ is a variable, not a macro.
Hence this #ifndef check does not work as intended, and only serves to
unconditionally disable __func__. A nonoperating __func__ prevents
cmocka operating correctly, so remove this definition.
Samba BUG: https://bugzilla.samba.org/show_bug.cgi?id=15134
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Change-Id: Ieac3937b9e86f39e84c0c056ffd649e44b292099
On systems where 'unsigned long' is 32-bits and the 'size'
parameter is set to 8 and the bytes are:
0x78 0x00 0x00 0x00 0x00 0x00 0x00 0x00
When 'i' becomes 4 'v' will be 0 again. As 'unsigned long' is only
able to hold 4 bytes.
Change the type of 'v' from 'unsigned long' to 'uint64_t' which
matches the type of the output parameter 'value'.
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
CVE: CVE-2022-42898
Samba-BUG: https://bugzilla.samba.org/show_bug.cgi?id=15203
We set the timestamp field of krb5_keytab_entry in every case in-tree,
so we should not clobber it in krb5_kt_add_entry(). This is very
important in the context of virtual service principals, as the timestamp
of the keys in the keytab is a clue to when they must be refetched!
The 'bits' parameter to select_dh_group() is the minimum acceptable
bit size. Rename 'bits' to 'min_bits' and fix the comparision
with krb5_dh_moduli.bits to ensure that DH groups whose bit size
is the minimum acceptable are not excluded.
Fixes#1002
Reported-By: Julien Rische (GitHub: jrisc)
Heimdal supports the 2 mandatory MODP groups (group 2 and group 14)
according to RFC4556, however group 14 is defined with a size of
1760 bits instead of 2048.
Fixes#1001
Reported-by: Julien Rische (GitHub: jrisc)
Apple clang version 14.0.0 (clang-1400.0.17.3.1) fails the build
because stds.h defines `fallthrough` as a macro which is then
expanded when base.h evaluates
# if __has_attribute(fallthrough) && __clang_major__ >= 5
The macOS SDK defines `DISPATCH_FALLTHROUGH` as the macro instead
of `fallthrough`.
This change replaces the use of `fallthrough` in the tree with
`HEIM_FALLTHROUGH` and updates the declaration in configure logic
to define `HEIM_FALLTHROUGH` based upon existing definitions
(if any) of `fallthrough` or `DISPATCH_FALLTHROUGH`.
If the AP len is large enough, we might end up computing an address
beyond the end of the 'reply' array, which is undefined behaviour.
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Now that we use krb5_copy_context() via kadm5_c_dup_context(), we see
occasional skew errors in the tests because context->max_skew was not
being initialized, so it was set to 0s of skew, and krb5_rd_priv() or
others could fail.
In a cross-realm situation the client KDC exchange may use on orphaned
strengthen_key (from the previous exchange) if the current KDC
doesn't not support FAST and the previous KDC supported it.
Otherwise init_creds_step() or fast_tgs_strengthen_key()
generate the reply key.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15005
Signed-off-by: Stefan Metzmacher <metze@samba.org>
