Package: libapache-mod-php4
Version: 4:4.3.10-8
Severity: normal
After upgrade to latest apache/php4 I noticed a different behavior of
fsockopen on unix domain sockets. Previously following worked:
[1] $fd = fsockopen("unixsocket",0);
Now you must replace this by
[2a] $pwd = getcwd();
[2b] $fd = fsockopen("$pwd/unixsocket",0);
to get the old behavior again where unixsocket was searched relative to
the path the script executed. I think the previous behavior shall be
desired one, as it's what you would expect that fsockopen does.
Please note that it makes no sense to me that now line [1] tries to open
/unixsocket (in fact it does this, I checked it) and the script has to
refer to/know it's CWD to get the desired behavior again.
If this is a safe mode issue, then the path shall be ignored alltogether
and the socket shall be caged into a safe mode directory (but I doubt
it has something to do with safe mode as the path works as expected).
I am not aware of any debian packages which rely on fsockopen with unix
sockets, but it broke one of my scripts (else I would not have come
across this issue) which ran on a variety of PHP installations before ..
Quick example to reproduce this bug:
Put script sock.php somewhere at your webbrowser's document root:
<?
header("content-type: text/plain");
# Notice the v missing slash!
$fd=fsockopen("tmp/testsock",0,&$e,&$s);
echo "($e) $s";
fwrite($fd, "Hello world\n");
?>
Call at a terminal:
umask 000; accept "</tmp/testsock"; rm -f /tmp/testsock
# you can get "accept" at (yes, accept is a poor name for it):
# http://www.scylla-charybdis.com/download/accept-2.0.0.tar.gz
# !!! Remember not to trust me, recompile accept yourself ;)
# I am not aware of other tools which are able to accept/connect to
# unix domain sockets (netcat etc. are only able to use TCP).
Now open sock.php from your webbrowser and notice the output of the
accept tool. How has the PHP script (which does not contain an absolute
path!) found the socket in /tmp ?
-Tino
PS: I checked the recent bugs and did not find fsockopen mentioned.
Sorry if this is a dupe. Thank you!
PPS: I was unable to reproduce this bug with the PHP4 CLI. CGI not
tested.
-- System Information:
Debian Release: 3.1
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.4.27
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages libapache-mod-php4 depends on:
ii apache-common 1.3.33-4 support files for all Apache webse
ii debconf [debconf-2.0] 1.4.30.11 Debian configuration management sy
ii libbz2-1.0 1.0.2-5 high-quality block-sorting file co
ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an
ii libcomerr2 1.35-6 The Common Error Description libra
ii libdb4.2 4.2.52-18 Berkeley v4.2 Database Libraries [
ii libexpat1 1.95.8-1 XML parsing C library - runtime li
ii libkrb53 1.3.6-1 MIT Kerberos runtime libraries
ii libmagic1 4.12-1 File type determination library us
ii libpcre3 4.5-1.1 Perl 5 Compatible Regular Expressi
ii libssl0.9.7 0.9.7e-2 SSL shared libraries
ii libzzip-0-12 0.12.83-4 library providing read access on Z
ii mime-support 3.28-1 MIME files 'mime.types' & 'mailcap
ii php4-common 4:4.3.10-8 Common files for packages built fr
ii zlib1g 1:1.2.2-3 compression library - runtime
-- debconf information:
php4/update_apache_php_ini: true
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
