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.
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>
The lib/kadm5/test_marshall program allows one to construct and check
encodings for various struct types for which we have
{kadm5,krb5}_{ret,store}_<type>() functions.
Currently supported are:
- krb5_keyblock
- krb5_principal
- krb5_times
- krb5_address
- krb5_addresses
- krb5_authdata
- krb5_creds
- krb5_key_data
- krb5_tl_data
- kadm5_principal_ent_rec
With this we'll be able to a) construct test vectors, b) use those to
drive fuzzing with AFL or other fuzzers.
Add rk_undumptext(), which NUL-terminates the contents it reads.
rk_undumptext(), and now also rk_undumpdata(), can read from regular and
non-regular files (e.g., ttys, pipes, devices, but -on Windows- not
sockets).
This means that `asn1_print` can now read from `/dev/stdin`, which can
be a pipe.
There's a way to set a limit on how much to read from non-regular files,
and that limit defaults to 10MB.
At any rate, the rk_dumpdata(), rk_undumpdata(), and rk_undumptext() functions
really do not belong in lib/roken but in lib/base. There are other utility
functions in lib/roken that don't belong there too. A rationalization of the
split between lib/roken and lib/base is overdue. And while we're at it -lest I
forget- it'd be nice to move all the krb5_storage functions out of lib/krb5 and
into lib/base, as those could come in handy for, e.g., implementing OpenSSH
style certificates and other things outside the krb5 universe.
The bug fixed herein almost certainly means that PKINIT was never
working on Windows, since lib/hx509 uses rk_undumpdata() to read regular
files containing certificates and keys, but then since rk_undumpdata()
was using net_read(), that can't have worked. On Windows net_read()
insists on the FD being a socket, and because of winsock, the namespaces
of socket and file descriptors on Windows are distinct.
hxtool is a very useful command, with a very user-friendly interface, at
least compared to OpenSSL's openssl(1). We should document it better.
Currently there are no manual pages for hxtool(1)'s subcommands, though
their --help message is pretty self-explanatory. Now the hxtool(1) page
provides better clues to the user, including examples.
