Per unix(7):
abstract: an abstract socket address is distinguished (from a
pathname socket) by the fact that sun_path[0] is a null byte
('\0'). The socket's address in this namespace is given by the
additional bytes in sun_path that are covered by the specified
length of the address structure. (Null bytes in the name have no
special significance.) The name has no connection with filesystem
pathnames. When the address of an abstract socket is returned,
the returned addrlen is greater than sizeof(sa_family_t) (i.e.,
greater than 2), and the name of the socket is contained in the
first (addrlen - sizeof(sa_family_t)) bytes of sun_path.
The existing implementation was assuming significance in null bytes
contained in the abstract address identifier.
musl libc is complaining when <sys/poll.h> is used instead of <poll.h>
so change this.
This issue was reported for OpenWrt/LEDE where musl libc is the standard
C library instead of e.g. glibc, see the following link for the original PR:
https://github.com/openwrt/packages/pull/4263
Signed-off-by: Philip Prindeville <philipp@redfish-solutions.com>
Signed-off-by: Michael Heimpold <mhei@heimpold.de>
--
v3: refined checks/fallback paths as suggested by @bukka
v2: rebased to resolve merge conflict in main/php_network.h
v1: initial PR
While the case in bug #74429 is not documented and is only worky due to
an implementation bug, the strength seems to breach some real world
apps. Given this patch doesn't impact the initial security fix for
bug #74216, it is reasonable to let the apps keep working. As mentioned
in the ticket, this behavior is a subject to change in future versions
and should not be abused.
```
In file included from /usr/local/include/php/main/php_network.h:124:0,
from /var/www/html/php-ext-handlersocketi-0.0.1/hs_response.c:3:
/usr/include/sys/poll.h:1:2: warning: #warning redirecting incorrect #include <sys/poll.h> to <poll.h> [-Wcpp]
#warning redirecting incorrect #include <sys/poll.h> to <poll.h>
^
```
For historical reasons, fsockopen() accepts the port and hostname
separately: fsockopen('127.0.0.1', 80)
However, with the introdcution of stream transports in PHP 4.3,
it became possible to include the port in the hostname specifier:
fsockopen('127.0.0.1:80')
Or more formally: fsockopen('tcp://127.0.0.1:80')
Confusing results when these two forms are combined, however.
fsockopen('127.0.0.1:80', 443) results in fsockopen() attempting
to connect to '127.0.0.1:80:443' which any reasonable stack would
consider invalid.
Unfortunately, PHP parses the address looking for the first colon
(with special handling for IPv6, don't worry) and calls atoi()
from there. atoi() in turn, simply stops parsing at the first
non-numeric character and returns the value so far.
The end result is that the explicitly supplied port is treated
as ignored garbage, rather than producing an error.
This diff replaces atoi() with strtol() and inspects the
stop character. If additional "garbage" of any kind is found,
it fails and returns an error.
php_check_open_basedir() expects a local filesystem path,
but we're handing it a `glob://...` URI instead.
Move the check to after the path trim so that we're checking
a meaningful pathspec.
As fcgi_request is an opaque struct as of PHP 7, expose a new API
function fcgi_end() which does fcgi_flush() with end=1 and checks/
sets the ->ended flag.
"closed" refers to whether FCGI_END_REQUEST has been sent, while
the "close" operation does something entirely different. It gets
extra confusing when fcgi_is_closed() does not actually return
fcgi_request.closed...
