The ucred_t argument must be initialized to zero otherwise it is assumed to
point to allocated memory. Also, the logic is inverted: getpeerucred()
returns zero on success, not failure.
In the interest of being paranoid, when a WinCNG crypto or digest
context is being reinitialized, zero out the backing store as well
as destroying the handle.
This is required as the PKCS#11 library needs to be reinitialized after
forking. This was causing a problem with ipropd.
This fix appears to incur a repeatable 10ms performance penalty on aes-test.
Caching the initialization status using a once control and invalidating it
on fork provided no measurable performance benefit on Solaris 11. Other
approaches would not be thread-safe or would involve more intrusive code
changes, such as exposing heimbase's atomics.
Similar fix to a88d0066, but for the WinCNG EVP backend. However this
is just a fix for leaking handles if the same EVP context is used with
a new key; there is no functionality issue as cipherstate is maintained
directly in the EVP context, not internally by WinCNG.
Clients of the EVP API can reinitialize message digest contexts
without destroying them. The PKCS#11 backend assumed they were
only used once, and was leaking session handles upon reinitialization.
This fix disposes of any existing PKCS#11 message digest context
in the initialization method.
Some callers of EVP_DigestUpdate (such as libntlm) pass NULL as the
data argument. PKCS#11 returns CKR_ARGUMENTS_BAD which may poison
the context. Pass an empty string to C_DigestUpdate work around this.
81c778e broke the PKCS#11 hcrypto backend broke for many cases as it did
not support cipherstate resetting. (Prior to 81c778e, which was to fix#194,
the PKCS#11 backend did not support cipherstate chaining across invocations.)
hcrypto backends that maintain cipherstate independently of the hcrypto
context IV field need to set EVP_CIPH_ALWAYS_CALL_INIT to avoid the two
diverging. Their init function should support resetting the cipherstate
independently of key scheduling.
Solaris make won't allow @echo in a shell command string as there is no
command called @echo, and it passes the whole shell command to the shell
without poaching off the @ itself first
despite the fact that the called function returns void,
returning a result here throws an error with solaris cc.
just call the function and don't return
camellia-ntt had none of its symbols renamed into the hc_ namespace,
and rand's missed timer_method (while all other methods were done). rename
these like we do for others
if when we need to determine if getauxval sets errno, we determine it doesn't
after getting a 0 return code, make sure we return a value, since we didn't
previously. fall through to code we'd otherwise have called in this case
above.
This can happen in the error path when processing malformed AS
requests with a NULL client name. Bug originally introduced on
Fri Feb 13 09:26:01 2015 +0100 in commit:
a873e21d7c
kdc: base _kdc_fast_mk_error() on krb5_mk_error_ext()
Original patch by Jeffrey Altman <jaltman@secure-endpoints.com>
depending what's available when you compile for iOS it's possible to
be __APPLE__ and not have CF; actually test for it instead of blythely
assuming it can be used
- Simplify child process creation rate limit by moving
select_sleep() to happen right after the parent fork().
- Consider child pid table slots to be empty if the pid is
non-positive, rather than just -1 or just 0.
- Log warnings should we ever spawn a child with no free
slot to track it, or reap a child that does not match
a tracked slot.
This allows the optimized checksum->verify() function to be used.
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
(cherry picked from Samba commit fb318ab0203297019c5e47c6bef4a9abfdeea8a5)
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
(cherry picked from Samba commit 05cc099499ef3a07d140981ef82937c842a3ffef)
Doing an fsync per-record when receiving the complete HDB is a performance
disaster. Among other things, if the HDB is very large, then one slave
receving a full HDB can cause other slaves to timeout and, if HDB write
activity is high enough to cause iprop log truncation, then also need full
syncs, which leads to a cycle of full syncs for all slaves until HDB write
activity drops.
Allowing the iprop log to be larger helps, but improving receive_everything()
performance helps even more.
This reverts commit ccb63bb0aa, which was
unnecessary and broke tests/kdc/check-kadmin (and other things).
host->port happens to be an unsigned short, so that promotion to an integer in
the snprintf() call is safe in that the promoted value will still be
non-negative, and no larger than an unsigned short's maximum value. We're
still assuming that 7 bytes is sufficient to hold the text representation of
that maximum value, which indeed it is, assuming sizeof(unsigned short) == 2
and CHAR_BIT == 8, which are fair assumptions here. A better patch, if we
needed it, would be to just make portstr[] an array of 11 char, or perhaps make
it a VLA (but we can't yet use VLAs, I don't think, because of older Windows
systems that must be supported still).
