Due to the issue described in c641974, purge() inadvertently destroyed
CA certificates that should have been kept (while the pointer to these
objects remained in the array). This lead to incorrect reference counts
and after a few reauthentications with multiple authentication rounds,
which cause calls to purge(TRUE), to crashes.
Because enumerate() for value based arrays returns a pointer directly to
the internal array elements and because array_remove_at() or rather the
called array_remove() may move elements over the element at the currently
enumerated position, the pointer passed to enumerate() will point to a
different array element after the array_remove_at() call. The caller
will thus operate on the wrong element if that pointer is accessed again
before calling enumerate().
For performance reasons we currently don't change the implementation to copy
each array element during enumeration to a private member of the enumerator and
return a pointer to that. Similarly, due to the danger of subtle bugs we don't
remember the pointer passed to enumerate() to later redirect it to a copy
created during the array_remove_at() call.
In the previous implementation queued jobs could prevent a service from
getting destroyed. This could have lead to a deadlock when the
processor is cancelled. Now destroy() still blocks, but waits only for
actually running tasks. The service instance is reference counted so that
queued jobs can safely be destroyed.
Calling on_accept() sometimes lead to deadlocks when service->destroy()
was called concurrently. That is, two threads waiting in on_accept() but
the last worker would only wake one due to the call to signal(). Calling
broadcast() wouldn't help either as that could lead to crashes if the thread
that called destroy() is woken first.
This is also more efficient as a constant pool of concurrent workers can
be maintained, otherwise peaks at the limit were followed by only a single
worker being active.
Because this->thread is also read by threads that don't hold the
mutex the previous implementation was problematic (especially since
pthread_t is an opaque type of unknown length).
Fixes#654.
This won't hurt as long as sets and validators are of the same class.
But as soon as one of the object's class is changed this will cause
either a compile error (best option), or result (most likely) in a
crash.
Signed-off-by: Thomas Egerer <[email protected]>
To avoid any race conditions when multiple threads call and initialize
diffie_hellman_get_params(), explicitly examine the optimum DH exponent size
during library initialization.
Fixes#655.
As the behavior was inconsistent for empty strings or strings with characters
appended to a number, testing the code failed on some platforms. The new rules
are more strict, returning the default if additional characters or an empty
string was found for a setting.
While glob should return a NULL terminated gl_pathv when having no matches,
at least on OS X this is not true when using GLOB_DOOFFS. Rely on the
number of matches returned in gl_pathc, which seems to be more reliable in
error cases.
Starting with libgcrypt 1.6, it seems that custom locking functions are not
supported anymore. Instead, the user has to select from one of the pre-defined
set of locking functions.
Given that we have a proper threading abstraction API with optional profiling
on all platforms, this is somewhat annoying. However, there does not seem to be
a way to use custom functions, and we have no other choice than using the
provided macro magic to support all libgcrypt versions.
Fixes#630.
fstat() in newer MinGWs is defined as non-static inline. With our new static
inline memset()/memcpy() overloads, this raises a warning. To avoid it,
explicitly include <sys/stat.h> once before defining these overloads.
On Fedora, SELinux complains about these open file descriptors when the
updown script invokes iptables. While it seems difficult to set the flag
on all file descriptors, this at least fixes those covered by the SELinux
policy.
As these two cases are in code executed while the daemon is still single
threaded, we avoid the use of atomic but not fully portable fdopen("e") or
open(O_CLOEXEC) calls.
Fixes#519.
These wrappers guarantee that calls to these functions are noops if the
number of bytes is 0, as calling them with NULL pointers is undefined
according to the C standard, even if the number of bytes is 0 (most
implementations probably ignore the pointers anyway in this case, but
lets make sure).
Tobias Brunner