As the atomics are signed on AIX, we better try to use the largest
possible max value.
The 'int' API uses 32-bit values for both 32-bit and 64-bit binaries:
typedef int *atomic_p;
int fetch_and_add(atomic_p addr, int value);
The 'long' API uses 32-bit values for 32-bit binaries and 64-bit values
for 64-bit binaries:
typedef long *atomic_l;
long fetch_and_addlp(atomic_l addr, long value);
So we better use the 'long' API in order to avoid any potential
problems with the heim_base_atomic_integer_max magic value, where
INT[32]_MAX would be a little bit low compared to 64-bit pointer space.
Signed-off-by: Stefan Metzmacher <metze@samba.org>
The API looks like this on AIX:
typedef int *atomic_p;
int fetch_and_add(atomic_p addr, int value);
The strange thing is that the xlc compiler ignores missing arguments by
default. (It warns but doesn't fail to compile)
As a result the value argument was just uninitialized memory,
which means that the ref_cnt variable of struct heim_base,
gets unpredictable values during heim_retain() and heim_release(),
resulting in memory leaks.
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>
While the local stack pointers could be thought of as "only"
numbers that are not invalidated by the memory they point at
being freed, any use of the pointer after the free is undefined
and so warned about (at best).
gcc version 12.2.1 20220819 (Red Hat 12.2.1-1) (GCC)
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
The idea with HEIM_JSON_F_TRY_DECODE_DATA is that on parsing of JSON
texts, if we find a base64-encoded string, decode it. But a lot of
strings that aren't base64-encoded can be decoded anyways, leaving a
mess.
Insted we should -in a future commit- implement this only for the string
values of "heimdal-type-data-76d7fca2-d0da-4b20-a126-1a10f8a0eae6" names
in singleton objects.
- Add HEIM_JSON_F_ESCAPE_NON_ASCII to indicate that non-ASCII must be
escaped as \uXXXX.
- Add HEIM_JSON_F_NO_ESCAPE_NON_ASCII to force non-escaping of BMP
codepoints.
- If the locale's codeset is not UTF-8 and
HEIM_JSON_F_NO_ESCAPE_NON_ASCII is not set, then set
HEIM_JSON_F_ESCAPE_NON_ASCII.
- Add flags for indenting with 2, 4, or 8 spaces, still defaulting to
tabs if none of those are set.
- Don't emit a newline before emitting scalar values in dicts.
This is needed so that it can be optional for path token expansion,
which has to have the context be optional for ccapi (lib/krb5/acache.c),
which in some cases calls path token expansion functions w/ a NULL
context.
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
Make krb5_pac a heim_object_t and use heim_retain() (i.e. reference count +1)
as the copy constructor for the type decoration.
Note: this assumes that PACs included in naming attributes are immutable.
Use uintptr_t for hash type; this is consistent with CoreFoundation, which uses
32-bit integers on 32-bit platforms for the hash code, and 64-bit integers on
64-bit platforms. (libheimbase is modelled on CoreFoundation.)
Previously we used unsigned long, which would have the same behavior on
LP32/LP64 systems, but not on Windows (where unsigned long is 32-bits on 64-bit
platforms).
Now heim_audit_addkv() correctly supports multiple values, the other functions
that (by design) replace existing values with a single value should use the
heim_audit_setkv prefix.
A subsequent commit could add variants that support multiple values for
non-string types.
Previously, if heim_audit_vaddkv() was called multiple times, values would be
concatenated; since changing the request kv type to a dictionary, only the most
recently set value was preserved.
Fix this by promoting multi-valued values to an array of values, which is
visualized in the same manner as it was prior to b1dcc1a4.
The auth event details audit key (formerly, parameter to auth_status)
contained, variously, an encryption type name; a PKINIT client certificate
name; or, a GSS initiator name. Audit these instead using individual keys that
reflect the values' contents.
