php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Doc Bug #79905 Console-less environments do not prevent std streams to be opened
Submitted: 2020-07-28 11:37 UTC Modified: 2022-10-06 10:49 UTC
Votes:3
Avg. Score:4.7 ± 0.5
Reproduced:3 of 3 (100.0%)
Same Version:3 (100.0%)
Same OS:2 (66.7%)
From: chokolatrix at gmail dot com Assigned:
Status: Open Package: CGI/CLI related
PHP Version: 7.4.8 OS: WINDOWS
Private report: No CVE-ID: None
View Developer Edit
 [2020-07-28 11:37 UTC] chokolatrix at gmail dot com 
Description:
------------
PHP's fopen() should fail to:
- open read-only streams in write mode (STDIO in 'w' or other write modes)
- open write-only streams in read mode (STDOUT, STDERR etc. in 'r' or other read modes)

This was noticed because of Laravel's logging to stderr failing under Apache/2.4.29 (Win64) mod_fcgid/2.3.9 and PHP 7.4.8 x64 NTS. 

There is possibly a bug with Apache and FastCGI exposing STDERR as non-writable (normally writes STDERR to the error log), but Laravel logging code checks fopen() result being a stream before writing to it.



Test script:
---------------
<?php
# c:\my-site\test.php

error_reporting(E_ALL);
ini_set('display_errors','On');

$fp = fopen('php://stdin', 'w');
var_dump($fp);

$fp = fopen('php://stderr', 'r');
var_dump($fp);

if ($fp) {
    // this then fails on Apache + FastCGI - might be an Apache + FCGI bug causing stderr not to be writable
    fwrite($fp, "test");
} 


Expected result:
----------------
bool(false)
bool(false)


Actual result:
--------------
Notice: fwrite(): write of 4 bytes failed with errno=9 Bad file descriptor in test.php on line 7

resource(3) of type (stream)
resource(4) of type (stream)

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2020-07-28 12:08 UTC] chokolatrix at gmail dot com 
Related: https://bugs.php.net/bug.php?id=79166
 [2020-07-30 12:56 UTC] cmb@php.net 
The fact that opening the 'output', 'input', 'stdin', 'stderr' and
'fd' protocols completly ignores the given $mode[1], looks
actually wrong to me.

However, on Windows with IIS *F*CGI there is usually no stderr
(nor stdout for that matter); all communication with the Webserver
is done through a pipe.  The fact that PHP allows to open
php://stderr is certainly a bug in this case.

[1] <https://github.com/php/php-src/blob/php-7.4.8/ext/standard/php_fopen_wrapper.c#L215-L341>
 [2020-09-22 09:15 UTC] cmb@php.net 
Related To: Bug #76086
 [2021-12-07 17:01 UTC] cmb@php.net
-Assigned To: +Assigned To: cmb
 [2021-12-09 17:54 UTC] cmb@php.net
-Summary: fopen() read-only streams in write mode doesn't fail +Summary: Console-less environments do not prevent std streams to be opened
 [2021-12-09 17:54 UTC] cmb@php.net 
> The fact that opening the 'output', 'input', 'stdin', 'stderr' and
> 'fd' protocols completly ignores the given $mode[1], looks
> actually wrong to me.

On further consideration, I don't think that qualifies as a bug;
it is merely something to be documented, and that has been
done[1].  Emitting a notice if a mode is passed which does not
match, might be an improvement, but is not strictly necessary.

It is also not necessary to give an option to open php://stderr in
read-write mode; while POSIX mandates[2] that stderr is expected
to be open for reading and writing, this is not supported on
Windows, and likely there is no real need for that.  Furthermore,
on CLI, STDERR could be used instead, what is supposed to follow
POSIX semantics on POSIX conforming platforms.

[1] <https://github.com/php/doc-en/commit/c5c3a4153df3b8c8007a33488f676e31b8e0f906>
[2] <https://pubs.opengroup.org/onlinepubs/9699919799/functions/stdin.html>
 [2021-12-14 11:45 UTC] cmb@php.net
-Type: Bug +Type: Documentation Problem -Assigned To: cmb +Assigned To:
 [2021-12-14 11:45 UTC] cmb@php.net 
> The fact that PHP allows to open php://stderr is certainly a bug
> in this case.

While that is indeed not nice, and could be prevented, the more
serious issue is that php://stdin can be opened, but reading from
it would likely hang indefinitely under FCGI, since stdin is
actually FCGI_LISTENSOCK_FILENO (i.e. a pipe on Windows), and
detecting this is non-trivial, unless we would expose that info
from the SAPIs.

It's probably best to leave the implementation as is, and to
document the limitation instead.
 [2022-10-06 10:49 UTC] bukka@php.net
-Package: Filesystem function related +Package: CGI/CLI related
 [2022-10-06 10:49 UTC] bukka@php.net 
So this is specific to CGI SAPI and it might be also good to check if it can do the same thing on Windows as FPM does on Linux - it means redirect those streams to be still usable.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Tue Dec 03 17:01:29 2024 UTC