|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #44127 UNIX abstract namespace socket connects does not work
Submitted: 2008-02-15 08:33 UTC Modified: 2008-07-16 18:51 UTC
Avg. Score:4.7 ± 0.5
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: pz4u at vplace dot de Assigned: jani (profile)
Status: Closed Package: Streams related
PHP Version: 5.2.5 OS: Linux
Private report: No CVE-ID: None
 [2008-02-15 08:33 UTC] pz4u at vplace dot de
I'm currently developing a binding for D-BUS based on native PHP. For that reason I need to talk to abstract namespace sockets. It seems like PHP is handling these socket type differently than D-BUS. I can't connect to the abstract socket.

I asked for help on the php-general mailing list and got some helpful responses for further investigation:

After that I asked on the D-BUS mailing list for clarification how D-BUS implements abstract namespace support:

As pointed out by Havoc on the dbus mailing list I think the problem is here:
or in the stream version of this API (not sure if it uses the same functions).

- I'm wondering why 108 is hardcoded here (in the connect function). A constant might be better?
- "If the connect() or listen() just does sizeof(struct sockaddr_un) then it will always get a bunch of trailing garbage bytes in the abstract name." (quoted Havoc here)
- Even if their is no NUL byte to mark the end of the string PHP should only use non-nul byte characters for the path (or better: the string that has been given by the programmer.) If a programmer want's to fill up sun_path with NUL bytes, it should be added to the PHP code and not "assumed".

I'm not a C programmer - so the code in sockets.c might just do what I wrote - I'm sorry for any inconveniences in this case.

This seems to be a regression of bug #16121

Reproduce code:
// use env to find a current abstract D-BUS socket

$fp = fsockopen ("unix://\x00/tmp/dbus-whatever",0);
if ($fp) { fclose ($fp); }

Expected result:
A connect with \x00/tmp/dbus-whatever (without added NUL bytes until the maximum sun path length is reached).

Actual result:
fsockopen(): unable to connect to unix://:0 (Connection refused)

for unix://\x00/tmp/dbus-whatever which is a bit strange because I expected at least the error message "fsockopen() [function.fsockopen]: unable to connect to unix://[NUL byte]/tmp/dbus-whatever:0 (Connection refused)"

stream_socket_client: unable to connect to unix://\0/tmp/hald-local/dbus-ZniNmvr5O0 (Connection refused) in ...

Warning: socket_connect(): unable to connect
[22]: Invalid argument in ...

I can garantuee that the arguments are right - removing the NUL byte from socket_connect allows me to connect to a non-abstract socket.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2008-02-19 23:25 UTC] apenwarr at gmail dot com
The problem here is definitely the sockaddr length being passed by php.  Here's what php does according to strace:

connect(3, {sa_family=AF_FILE, path=@/tmp/dbus-8qswtYDtSn}, 110) = -1 ECONNREFUSED (Connection refused)

And here's what a working C++ program does:

connect(3, {sa_family=AF_FILE, path=@/tmp/dbus-8qswtYDtSn}, 23) = 0

Notice the only difference is 110 vs 23.  The "@" sign is displayed by strace to mean an abstract socket (first character of the path is null); when connecting to an abstract socket, the path= variable is not displayed in quotes like it normally would be.

23 = sizeof(sa_family) + length(path)
 [2008-07-16 14:13 UTC]
This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
Thank you for the report, and for helping us make PHP better.

Both ext/sockets/ and streams implementations are fixed now.
PHP Copyright © 2001-2019 The PHP Group
All rights reserved.
Last updated: Sat Mar 23 18:01:26 2019 UTC