Bug #66884 [Com]: php://fd/x file descriptors not usable outside CLI mode

From: 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

« previous php.bugs (#185199) next »