Fixed bug #78042

[KonstantinKuklin]

Incorrect readable and writable flags for php:// streams

[nikic]

I'd use something like S_IRUSR | S_IRGRP | S_IROTH | S_IWUSR | S_IWGRP | S_IWOTH here, to avoid the magic shift numbers.

[nikic]

Looking at

php-src/ext/standard/php_fopen_wrapper.c

Line 215 in 203535e

if (strpbrk(mode, "wa+")) {

and similar code, I don't think we can unconditionally say that these streams are read+write, it seems that there are also read-only modes.

I'm not really familiar with stream code -- would it be possible to implement fstat rather than stat, where we have access to the underlying stream, to fulfil the purpose here?

[KonstantinKuklin]

Yes, the stream could be open only for read, or only for write or both.
Here I just provide information how the PATH(or sometimes it names URL in code) can be opened.
If u have file example.txt with RW, u should see that the file is able to open for read and for write - this information not related to any your stream to this file path and stream flags.

php-src/main/php_streams.h

Lines 140 to 143 in 9a74b23

	/* stat a wrapped stream */
	int (*stream_stat)(php_stream_wrapper *wrapper, php_stream *stream, php_stream_statbuf *ssb);
	/* stat a URL */
	int (*url_stat)(php_stream_wrapper *wrapper, const char *url, int flags, php_stream_statbuf *ssb, php_stream_context *context);

In php_fopen_wrapper wrong comments, I implemented url_stat(path stat) which is I suppose correct for this case.

[nikic]

You're right, my comment about the mode was bogus, it's not relevant here.

However, I think that there might still be some issues with certain stream types. E.g. php://fd will be subject to the read/write mode of the original file descriptor, e.g. php://fd/0 should be read-only and php://fd/1 should be write-only, assuming they are stdin and stdout respectively. Similarly, for php://filter this probably also depends on the readability/writability of the wrapped resource.

[KonstantinKuklin]

Right now I don't know how to provide info about fd and filter, because if u set chmod 666 to /dev/fd/0 will it means php://fd/1 became RW?
If I skip with TODO this two points FD and FILTER can we merge fix for others?

[KonstantinKuklin]

thank u @nikic, fixed all remarks

[nikic]

Ignoring those cases seems fine for now. I think we might need to return -1 in that case though, to indicate that this is not supported. Can you also add a test for one of those (fd or filter) just so we see what the behavior will be?

[nikic]

This function still needs to be reindented to tabs.

[phansys]

Are these changes related to the return value of \SplFileInfo::getSize()? I've executed a test based on this PR and this method is returning 0 regardless the stream's contents:

Test

$file = new \SplFileObject('php://temp');
$file->fwrite('some content');
var_dump($file->getSize()); // prints 0
$fp = fopen($file->getPathname(), 'rb');
$stats = fstat($fp);
fclose($fp);
var_dump($stats['size']); // prints 0

[KonstantinKuklin]

@phansys yes
before this PR behavior was https://3v4l.org/91gfq

Fatal error: Uncaught RuntimeException: SplFileInfo::getSize(): stat failed for php://temp in /in/91gfq:5
Stack trace:
#0 /in/91gfq(5): SplFileInfo->getSize()
#1 {main}
thrown in /in/91gfq on line 5

Process exited with code 255.

[phansys]

Right @KonstantinKuklin, I noticed that fix, thank you so much. I mean, I thought that after these change, the return value of \SplFileInfo::getSize() would be other than 0 when there is content in the stream.

[KonstantinKuklin]

@phansys I'd say there should be still error message, because SplFileInfo is not about streams, but files. I will double check this behavior, thank you for case with size.

[krakjoe]

@nikic can you please give this one a final review and probably merge (I think it's all good now) ... ta

[cmb69]

What's the status here? The PR targets PHP-7.2, but would need to target PHP-7.4 or higher.

[cmb69]

I'm closing this PR due to inactivity. @KonstantinKuklin, feel free to rebase onto PHP-8.0 change the target branch accordingly, and re-open. Thanks for your work, anyway! :)