Bug->Doc #79905 [Asn]: Console-less environments do not prevent std streams to be opened

Edit report at https://bugs.php.net/bug.php?id=79905&edit=1

 ID:                 79905
 Updated by:         [email protected]
 Reported by:        chokolatrix at gmail dot com
 Summary:            Console-less environments do not prevent std streams
                     to be opened
 Status:             Assigned
-Type:               Bug
+Type:               Documentation Problem
 Package:            Filesystem function related
 Operating System:   WINDOWS
 PHP Version:        7.4.8
-Assigned To:        cmb
+Assigned To:        
 Block user comment: N
 Private report:     N

 New Comment:

> 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.


Previous Comments:
------------------------------------------------------------------------
[2021-12-09 17:54:28] [email protected]

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

------------------------------------------------------------------------
[2020-09-22 09:15:02] [email protected]

Related To: Bug #76086

------------------------------------------------------------------------
[2020-07-30 12:56:20] [email protected]

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-07-28 12:08:30] chokolatrix at gmail dot com

Related: https://bugs.php.net/bug.php?id=79166

------------------------------------------------------------------------
[2020-07-28 11:37:04] 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)



------------------------------------------------------------------------



--
Edit this bug report at https://bugs.php.net/bug.php?id=79905&edit=1