For each request, the worker calls the php_execute_script function
from libphp that changes to the script directory before doing its
work and then restores the process directory before returning. The
chdir(2) calls it performs are unnecessary in Unit design. In simple
benchmarks, profiling shows that the chdir syscall code path (syscall,
FS walk, etc.) is where the CPU spends most of its time.
PHP SAPI semantics requires the script to be run from the script
directory. In Unit's PHP implementation, we have two use cases:
- script
- arbitrary path
The "script" configuration doesn't have much need for a working
directory change: it can be changed once at module initialization.
The module needs to chdir again only if the user's PHP script also
calls chdir to switch to another directory during execution.
If "script" is not used in Unit configuration, we must ensure the
script is run from its directory (thus calling chdir before exec),
but there's no need to restore the working directory later.
Our implementation disables mandatory chdir calls with the SAPI
option SAPI_OPTION_NO_CHDIR, instead calling chdir only when needed.
To detect the user's calls to chdir, a simple "unit" extension is
added that hooks the built-in chdir() PHP call.
Temporary file name with configure process PID used to download
JAR from external repository. Then file renamed using command 'mv'.
The issue reproduced in clean environment when 2 or more concurrent builds
started.
The setuid/setgid syscalls requires root capabilities but if the kernel
supports unprivileged user namespace then the child process has the full
set of capabilities in the new namespace, then we can allow setting "user"
and "group" in such cases (this is a common security use case).
Tests were added to ensure user gets meaningful error messages for
uid/gid mapping misconfigurations.
This is required to avoid include cycles, as some nxt_clone_* functions
depend on the credential structures, but nxt_process depends on clone
structures.
Now the nxt_user_groups_get() function uses getgrouplist(3) when available
(except MacOS, see below). For some platforms, getgrouplist() supports
a method of probing how much groups the user has but the behavior is not
consistent. The method used here consists of optimistically trying to get up
to min(256, NGROUPS_MAX) groups; only if ngroups returned exceeds the original
value, we do a second call. This method can block main's process if LDAP/NDIS+
is in use.
MacOS has getgrouplist(3) but it's buggy. It doesn't update ngroups if the
value passed is smaller than the number of groups the user has. Some
projects (like Go stdlib) call getgrouplist() in a loop, increasing ngroups
until it exceeds the number of groups user belongs to or fail when a limit
is reached. For performance reasons, this is to be avoided and MacOS is
handled in the fallback implementation.
The fallback implementation is the old Unit approach. It saves main's
user groups (getgroups(2)) and then calls initgroups(3) to load application's
groups in main, then does a second getgroups(2) to store the gids and restore
main's groups in the end. Because of initgroups(3)' call to setgroups(2),
this method requires root capabilities. In the case of OSX, which has
small NGROUPS_MAX by default (16), it's not possible to restore main's groups
if it's large; if so, this method fallbacks again: user_cred gids aren't
stored, and the worker process calls initgroups() itself and may block for
some time if LDAP/NDIS+ is in use.
Python 3.8 has 'tp_print' field in PyTypeObject struct. This field is
attributed as deprecated. So, clang generates warning (which is turned to
error) as a result of initializing this field. From the other hand, it is
impossible to omit this field in positional initialization. The solution
is to use designated initializer.
Silencing usage message during configure python.
This is related to #331 issue on GitHub.
Currently almost all Unit object files depends on generated nxt_version.h.
This patch adds missing dependence and fixes running make with multiple
jobs.
This closes#318 issue on GitHub.
Some Perl compile options affects ABI and not using them while compiling
our module resulted in non-working build.
Notably on 32-bit Debian 10, Perl is built with -D_FILE_OFFSET_BITS=64
and our module after being compiled without this option caused segmentation
faults in unexpected places.
It's surplus option because the perl executable returns the proper path.
Also the Perl module configure script was cleaned up a bit.
Note that NXT_PERL_LDOPTS already contains the library path.
While it looks nicer without zero 3-rd version number, this should
improve interoperability. Version string can be parsed or used for
sorting. And it is easier to handle and less confusing when there
is constant number of version parts.
Moreover, NPM also expects version format with 3 parts.
So ".0" has already been used in Node.js module version.
By default "npm install" switches to non-privileged user to run package scripts
if it is invoked by root. As a result it may prevent node-gyp from writing to
package directory and break installation of the module.
To disable this switching the --unsafe-perm flag is added.
In most cases it is not needed because Ruby libraries are in the default path.
At the same time, rpath pointing to the default path is prohibited by rpmbuild
on Fedora.
This is related to issue #87 on GitHub.
Since PHP 7, a zend_signal_startup() call is required if the interpreter
was built with ZEND_SIGNALS defined; such a call was added in 3fd76e4ce70a.
However, the zend_signal_startup() export is missing from the PHP library;
as the result, dlopen() fails with the 'Undefined symbol "zend_signal_startup"'
error while loading the PHP module.
Meanwhile, if PHP is built without ZTS, the zend_signal_startup() call can
be omitted; otherwise, the missing call causes segmentation fault.
The PHP fix already was committed to upstream, but we still have to deal
with numerous unpatched versions remaining at large.
See the related PHP bug: https://bugs.php.net/bug.php?id=71041
