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

go to bug id or search bugs for

Bug #74556 stream_socket_get_name returns \0 string instead of false
Submitted: 2017-05-08 15:32 UTC Modified: 2017-12-21 17:53 UTC
Votes:4
Avg. Score:3.2 ± 1.5
Reproduced:0 of 0 (0.0%)
From: cpuidle at gmx dot de Assigned: pollita (profile)
Status: Re-Opened Package: Streams related
PHP Version: 7.1.7 OS: macOS
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: cpuidle at gmx dot de
New email:
PHP Version: OS:

 

 [2017-05-08 15:32 UTC] cpuidle at gmx dot de 
Description:
------------
When using UNIX sockets, php returns string(1) ''.\\0.'' for client side socket name of a client socket instead of false. 

See https://3v4l.org/VStV6

Internally, stream_socket_get_name (https://lxr.room11.org/xref/php-src%407.1/ext/standard/streamsfuncs.c) calls php_stream_xport_get_name (https://lxr.room11.org/source/s?refs=php_stream_xport_get_name&project=php-src@7.1).

The observed \0 string seems to be a returned empty C string buffer not further checked?

Test script:
---------------
<?php

$s = stream_socket_server('unix:///tmp/demo.sock');
$c = stream_socket_client('unix:///tmp/demo.sock');

var_dump(
    stream_socket_get_name($s, true),
    stream_socket_get_name($c, false)
);

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

Actual result:
--------------
bool(false)
string(1) ""

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2017-05-28 15:52 UTC] pollita@php.net 
Automatic comment on behalf of pollita
Revision: http://git.php.net/?p=php-src.git;a=commit;h=8dcfec9789b4792f7b6b25673274b74bae71b512
Log: Bugfix #74556 stream_socket_get_name() returns empty string
 [2017-05-28 15:52 UTC] pollita@php.net
-Status: Open +Status: Closed
 [2017-10-07 10:28 UTC] cpuidle at gmx dot de 
@pollita@php.net would you kindly explain why this bug has been closed without any comment? I've tried to provide every analysis I could including PHP sources. 

Doesn't that at least deserve a small token of appreciation like an answer?

Disappointed with the culture :(
 [2017-10-07 10:38 UTC] requinix@php.net
-Assigned To: +Assigned To: requinix
 [2017-10-07 10:38 UTC] requinix@php.net 
It was closed because it was fixed. And there *was* a comment for that - it was automatic so sorry if you wanted something more personal.
 [2017-10-07 10:40 UTC] requinix@php.net
-Assigned To: requinix +Assigned To: pollita
 [2017-10-07 10:42 UTC] spam2 at rhsoft dot net 
What is your problem?

There was a bugfix commited including a changelog entry pointing to this Bugreport - so what about you are whining?
 [2017-10-07 10:49 UTC] cpuidle at gmx dot de 
> It was closed because it was fixed. And there *was* a comment for that - it was automatic so sorry if you wanted something more personal.

Great. My mistake I didn't notice that- had expected it in the "changes" section, sorry for the confusion.

> What is your problem? There was a bugfix commited including a changelog entry pointing to this Bugreport - so what about you are whining?

I think that's the exact tone that doesn't attract people. If you read my comment you'll notice it wasn't rude...
 [2017-10-07 10:55 UTC] spam2 at rhsoft dot net 
"disappointed with the culture" when the fix was commited to 20 days after the report and within nearly 5 months you are NOT willing to read the existing comments or even update php where you would have seen it fixed and in the NEWS file *is rude*
 [2017-10-07 12:54 UTC] cpuidle at gmx dot de 
Mhm. The bug is in the changelog for 7.1.7 but I'm still seeing it (or something similar) in 7.1.8.

It has actually gotten worse (test case from this issue):

/Users/Documents/htdocs/vz/sock.php:8:
bool(false)
/Users/Documents/htdocs/vz/sock.php:8:
string(15) "\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000"

Instead of string(1) there's now a string(15) returned.

@Harald: I'll discontinue the side discussion with you.
 [2017-10-07 13:25 UTC] kelunik@php.net 
@rhsoft: Please stop with your tone. cpuidle simply missed a comment, which is probably caused by bugs.php.net's sub-optimal interface. It's nothing about willingness or something like that, it simply got missed.
 [2017-10-07 13:26 UTC] kelunik@php.net
-Status: Closed +Status: Re-Opened
 [2017-10-07 13:26 UTC] kelunik@php.net 
Re-opening, as behavior got worse.
 [2017-10-07 13:27 UTC] pollita@php.net
-Status: Re-Opened +Status: Closed
 [2017-10-07 13:27 UTC] pollita@php.net 
3v4l disagrees with you: https://3v4l.org/VStV6
 [2017-10-07 13:51 UTC] kelunik@php.net
-Status: Closed +Status: Re-Opened -Operating System: OSX +Operating System: macOS -PHP Version: 7.1.4 +PHP Version: 7.1.7
 [2017-10-07 13:51 UTC] kelunik@php.net 
It's still buggy on macOS, confirmed by bwoebi with yesterday's master.

Output
------

bool(false)
string(15) ""
 [2017-10-07 14:05 UTC] pollita@php.net 
Yep.  I just got done making a better repro and it looks like MacOS is just ever so slightly posix non-compliant here.  The spec still says any leading null byte should be considered abstract though, so I'll just check the check from len==0 to len==0 || *val=0 and should be gtg.
 [2017-10-07 14:15 UTC] pollita@php.net 
Automatic comment on behalf of pollita
Revision: http://git.php.net/?p=php-src.git;a=commit;h=843e492c6816fa18eff83a7a3e8c370531796912
Log: Bugfix #74556 stream_socket_get_name() returns null bytes on MacOS
 [2017-10-07 14:15 UTC] pollita@php.net
-Status: Re-Opened +Status: Closed
 [2017-10-07 14:16 UTC] pollita@php.net 
=============
ATTENTION!!!!
=============

THIS BUG HAS BEEN FIXED (we hope).
PLEASE REFERENCE THE ABOVE LINK TO GIT.PHP.NET FOR DETAILS ABOUT THE FIX.

=============
ATTENTION!!!!
=============
 [2017-10-07 14:21 UTC] cpuidle at gmx dot de 
@kelunik was faster than me and @pollita ever faster at fixing.

Much appreciated, thank you :)
 [2017-10-07 14:41 UTC] pollita@php.net 
You're welcome, and for the record: Thank you for the detailed bug report.  It was the details which meant it was (initially) fixed in 20 days instead of 200. :)
 [2017-12-18 00:12 UTC] kelunik@php.net
-Status: Closed +Status: Re-Opened
 [2017-12-18 00:12 UTC] kelunik@php.net 
The provided fix is incomplete / wrong. It breaks sockets using the abstract socket namespace on Linux. https://3v4l.org/RtaV2
 [2017-12-19 18:02 UTC] pollita@php.net 
Hrmmm.... Multiple layered things here.

How about:

    if ((ZSTR_LEN(name) == 0) ||
        ((ZSTR_LEN(name) == 1) && (ZSTR_VAL(name)[0] == 0))) {
        zend_string_release(name);
        RETURN_FALSE;
    }

That would return anything using an actual abstract socket path "\0/tmp/foo" but deal with the case where Mac returns "\0" for an unbound name,
 [2017-12-19 22:08 UTC] kelunik@php.net 
If I got it right then macOS returned multiple NUL-bytes? So that'd not work.
 [2017-12-19 23:19 UTC] pollita@php.net 
No, MacOS returns a single null byte which is nonsensical according to POSIX.
 [2017-12-21 17:53 UTC] pollita@php.net 
> string(15) ""
>
Ugh, wait, no... you're right.  That's a whole chunk of null bytes, isn't it?

Okay, I'm less keen on masking this behavior since the standard says that a leading null byte indicates abstract namespace with the following bytes providing the abstract identifier where "null bytes have no significance", which on a strict reading says that the "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0" output reported in this original bug is a valid indicator. (Even if it's probably nonsensical.)
 [2017-12-21 18:40 UTC] kelunik@php.net 
Yes. Until there's a better fix available, it's probably better to revert the fix for now, at least for Linux (as abstract socket namespace is Linux specific IIRC). Has this been reported to Apple? I guess it should really be fixed there?
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Tue Dec 03 17:01:29 2024 UTC