bugThe GNU Hurd - Bugs: bug #12434, Unix-domain (local) sockets do not...


bug #12434: Unix-domain (local) sockets do not support getsockname() or getpeername()

Submitter:  Marcus Brinkmann <marcus>
Submitted:  Wed 23 Mar 2005 09:18:30 PM UTC
Category:  Hurd Interfaces Severity:  1 - Wish
Priority:  1 - Later Item Group:  Compatibility
Status:  Confirmed Privacy:  Public
Assigned to:  None Originator Name:  deven@ties.org
Open/Closed:  Open Reproducibility:  Every Time
Size (loc):  None Planned Release:  None
Effort:  0.00
Wiki-like text discussion box: 

* Mandatory Fields

Add a New Comment Rich Markup

Wed 23 Mar 2005 09:23:34 PM UTC, comment #1: 

Calling getsockname() on a Unix Domain Socket does not seem to be widely supported.  I found the following two references:


> (fhandler_socket::getsockname): Call ::getsockname() even for UNIX
> domain sockets as an error check.

Note the formula: "as an error check".

The getsockname subroutine does not perform operations on UNIX domain sockets.

    Names bound to sockets in the UNIX domain are inaccessible; getsockname returns a zero length name.

There is a fundamental issue with supporting it: The filename used in the filesystem space in the creator may not be the same as one in the task querying it.

So, it is questionable what the semantics of this call on Unix Domain Sockets should be.

Marcus Brinkmann <marcus>
Group administrator
Wed 23 Mar 2005 09:18:30 PM UTC, original submission:  

Hi folks...

I'll start with a very brief introduction -- I just joined this mailing list, so that I could report a Hurd bug I found last night.  I never used the Hurd before yesterday, but I would be interested in working with it, if I can just find the time...

Anyway, I was on #hug on IRC last night, talking to "bddebian", who was having trouble getting "orbit2" (GNOME's CORBA broker) to run on the Hurd.  I offered to help, so he gave me an account on his machine and I traced the problem, which turned out to be that getsockname() was returning a null pathname instead of the correct pathname of the Unix-domain socket.  Since orbit2 expects this call to work, it broke the software.  After I found the problem, I stripped down the code to a 36-line test case (attached) which exhibits the bug.  Under Linux, getsockname() returns the same sockaddr_un structure that was sent to bind(), while the Hurd is returning a null path instead.

This morning, I took a quick glance at the Hurd sources, and noticed the following comment on S_socket_whatis_address() in hurd/pflocal/pf.c:

/* Implement socket_whatis_address as described in <hurd/socket.defs>.
   Since we cannot tell what our adress is, return an empty string as
   the file name.  This is primarily for the implementation of accept
   and recvfrom.  The functions getsockname and getpeername remain
   unsupported for the local namespace.  */

So it appears that no attempt was ever made to implement getsockname() or getpeername() for Unix-domain sockets.

Since this bug (unsupported feature) may break other applications
besides orbit2, perhaps someone would like to take a stab at  filling in the gap?


Marcus Brinkmann <marcus>
Group administrator


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files
file #2777:  getsockname_bug.c added by marcus (883B - text/x-csrc - Testcase for getsockname() on Unix Domain Socket)


Depends on the following items: None found

Items that depend on this one: None found


CC list is empty


There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

Only logged-in users can vote.


Follow 3 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2005-12-31 ams StatusNone Confirmed
2005-03-23 marcus Originator Name -email is unavailable-
2005-03-23 marcus Attached File- Added getsockname_bug.c, #2343

Back to the top

Powered by Savane 3.13-b921.
Corresponding source code