Bug #66884 [Com]: php://fd/x file descriptors not usable outside CLI mode
| From: | dfuhry at gmail dot com | Date: | Sun, 13 Apr 2014 01:48:04 +0000 |
| Subject: | Bug #66884 [Com]: php://fd/x file descriptors not usable outside CLI mode | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-185199@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=66884&edit=1
ID: 66884
Comment by: dfuhry at gmail dot com
Reported by: dfuhry at gmail dot com
Summary: php://fd/x file descriptors not usable outside CLI
mode
Status: Assigned
Type: Bug
Package: Streams related
Operating System: Linux 2.6.32-5-amd64
PHP Version: 5.6.0alpha3
Assigned To: stas
Block user comment: N
Private report: N
New Comment:
Thanks for pointing that out, I see slide 4 provides a concrete example of writing directly to the
file descriptor of the Apache error log.
A possible solution that comes to mind would be to either whitelist or blacklist descriptors by
either:
1) Tracking and whitelisting file descriptors created in user php code, like those created by a user
fopen() or pg_connect(), or
2) Blacklisting file descriptors not created in user php code, like file descriptor 2 corresponding
to the Apache error log as opened by PHP process code.
I'm not sure if there is a clean way to achieve either, while avoiding leaking any whitelist
descriptors or missing any blacklist descriptors, and working across platforms.
Previous Comments:
------------------------------------------------------------------------
[2014-04-13 01:14:14] tyrael@php.net
as far as I know it was changed, because it opened a can op worms from the security point of view,
see:
http://www.slideshare.net/phdays/on-secure-application-of-php-wrappers
------------------------------------------------------------------------
[2014-03-11 15:55:56] dfuhry at gmail dot com
Description:
------------
Commit df2a38e7f8603f51afa4c2257b3369067817d818 removed the ability to use php://fd/x file
descriptors in non-CLI mode. Thus, sometime after PHP 5.3 it became no longer possible to issue
parallel async database queries and stream_select on the array of database connection socket file
descriptors.
When trying to fopen("php://fd/x") (for some file descriptor number "x") the
unhelpful error I receive is: "failed to open stream: operation failed".
Neither the commit nor source comments make clear to me why the change was made, but if it is
possible to revert it, or otherwise make alterations to allow the above use case, I would advocate
doing so.
I use unexposed pg_socket() method in the below, which returns the file descriptor of the socket of
the database connection.
Test script:
---------------
$conn1 = pg_connect("dbname=a user=b host=c");
$conn2 = pg_connect("dbname=a user=b host=c");
// Next two lines should return resources representing file descriptors
// but instead error and return FALSE.
$r1 = fopen("php://fd/" . pg_socket($conn1));
$r2 = fopen("php://fd/" . pg_socket($conn2));
pg_send_query($conn1, "SELECT pg_sleep(random())");
pg_send_query($conn2, "SELECT pg_sleep(random())");
$r = array($r1, r2);
$w = array();
$e = array();
stream_select($r, $w, $e, NULL); // Would return whichever conn finished first.
Expected result:
----------------
fopen("php://fd/x") calls return a valid stream resource, not FALSE.
Actual result:
--------------
... failed to open stream: operation failed ...
... failed to open stream: operation failed ...
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=66884&edit=1