When an invalid TLS configuration is applied (such as the conf_commands
feature), nxt_cert_store_get() creates a buffer to send a certificate request
to the main process and adds its default completion handler to an asynchronous
queue to free the allocated buffer. However, if configuration fails,
nxt_router_conf_error() removes the memory pool used to allocate the buffer,
causing a crash when the completion handler is dispatched.
Assertion "src/nxt_buf.c:208 assertion failed: data == b->parent" is triggered
when is NXT_DEBUG enabled in the configure script.
This patch uses a reference counter to retain the memory pool and redefines the
completion handler to free the buffer before releasing the memory pool.
The idea is to put SAN after CN, but the previous version of the code
incorrectly assumed that CN was always present, which caused writes
outside the allocated object if there were no standard name attributes.
Previously, entries of any type were counted during object allocation
but only DNS type entries were actually processed. As a result,
if some certificate entries had another type, returning information
about the certificate caused uninitialized memory access.
It appears that readdir() on Linux detects file types unreliably, always setting
the "d_type" field to DT_UNKNOWN for some less common filesystems. As a result,
all files were skipped and no certificate bundles were found when the state
directory was located on such filesystems.
Skipping "." and ".." instead of any non-regular files should be enough, as no
other non-regular files normally appear in this directory.
This closes#368 issue on GitHub.
The process abstraction has changed to:
setup(task, process)
start(task, process_data)
prefork(task, process, mp)
The prefork() occurs in the main process right before fork.
The file src/nxt_main_process.c is completely free of process
specific logic.
The creation of a process now supports a PROCESS_CREATED state. The
The setup() function of each process can set its state to either
created or ready. If created, a MSG_PROCESS_CREATED is sent to main
process, where external setup can be done (required for rootfs under
container).
The core processes (discovery, controller and router) doesn't need
external setup, then they all proceeds to their start() function
straight away.
In the case of applications, the load of the module happens at the
process setup() time and The module's init() function has changed
to be the start() of the process.
The module API has changed to:
setup(task, process, conf)
start(task, data)
As a direct benefit of the PROCESS_CREATED message, the clone(2) of
processes using pid namespaces now doesn't need to create a pipe
to make the child block until parent setup uid/gid mappings nor it
needs to receive the child pid.
