get{peer,sock}name on AF_UNIX sockets

[Michael B Allen]

Is there a way to get the name of a unix socket like you
can using inet_ntoa with a regular socket? I thought perhaps
get{peer,sock}name might be suitable to then reference ((struct
sockaddr_un *)&addr)->sun_path but this information appears to be absent
or garbage (accept(2) returns len 2 and getsockname(2) claim the size
if the address is 18 bytes:

00000: 01 00 5d 00 8c 75 5e 00 58 fb e0 00 f0 2c e6 bf 98 26 \
|..]..u^.X....,...& |

but the offsetof sun_path is only 2).

Am I doing something wrong here?

Thanks,
Mike

[Michael B Allen]

Post by Michael B Allen
Is there a way to get the name of a unix socket like you
can using inet_ntoa with a regular socket? I thought perhaps
get{peer,sock}name might be suitable to then reference ((struct
sockaddr_un *)&addr)->sun_path but this information appears to be absent
or garbage (accept(2) returns len 2 and getsockname(2) claim the size
00000: 01 00 5d 00 8c 75 5e 00 58 fb e0 00 f0 2c e6 bf 98 26 \
|..]..u^.X....,...& |
but the offsetof sun_path is only 2).
Am I doing something wrong here?

At second glance getsockname(2) DOES work with AF_UNIX sockets (my length
parameter was being clobbered by accept(2)).

But accept(2) and getpeername(2) return a length of 2 which is just the
sa_family member. I guess the reasoning is that there is no such thing
as a remote address for a UNIX socket? Personally I would prefer to see
accept(2) and getpeername(2) return the sun_path also.

Oh, well,
Mike

[William Ahern]

Post by Michael B Allen

Post by Michael B Allen
Is there a way to get the name of a unix socket like you
can using inet_ntoa with a regular socket? I thought perhaps
get{peer,sock}name might be suitable to then reference ((struct
sockaddr_un *)&addr)->sun_path but this information appears to be absent
or garbage (accept(2) returns len 2 and getsockname(2) claim the size
00000: 01 00 5d 00 8c 75 5e 00 58 fb e0 00 f0 2c e6 bf 98 26 \
|..]..u^.X....,...& |
but the offsetof sun_path is only 2).
Am I doing something wrong here?

At second glance getsockname(2) DOES work with AF_UNIX sockets (my length
parameter was being clobbered by accept(2)).
But accept(2) and getpeername(2) return a length of 2 which is just the
sa_family member. I guess the reasoning is that there is no such thing
as a remote address for a UNIX socket? Personally I would prefer to see
accept(2) and getpeername(2) return the sun_path also.

Technically the peer name might have been deleted or renamed. AFAICT,
getting the sun_path from getsockname(2) is a nice convenience, but in
itself doesn't really fit with traditional Unix conventions. You can't get
the path of a file descriptor returned from opening a regular file, for
instance.

Plan9 said to hell with it, and got around all the inherent problems by
judging the passed path as "good enough". Linux took the hard road and tries
to track inode<->path mappings in the kernel--exposed through
/proc--but I think Plan9 made the better call.

[Michael B Allen]

Post by Michael B Allen
But accept(2) and getpeername(2) return a length of 2 which is just the
sa_family member. I guess the reasoning is that there is no such thing
as a remote address for a UNIX socket? Personally I would prefer to see

For the sake of completeness I have another correction.

If the AF_UNIX socket is a client oriented socket getpeername(2) does
fill in sun_path and getsockname(2) does not (whereas the reverse is
true of a server oriented socket).

But because the POSIX docs do not really specify what the proper behavior
is I suspect results on platforms other than Linux may not be consistent
with my observations.

Mike

[Frank Cusack]

Post by Michael B Allen
If the AF_UNIX socket is a client oriented socket getpeername(2) does
fill in sun_path and getsockname(2) does not (whereas the reverse is
true of a server oriented socket).

What is a client oriented socket, and what is a server oriented socket?
-frank

[Michael B Allen]

Post by Frank Cusack

Post by Michael B Allen
If the AF_UNIX socket is a client oriented socket getpeername(2) does
fill in sun_path and getsockname(2) does not (whereas the reverse is
true of a server oriented socket).

What is a client oriented socket, and what is a server oriented socket?

By "client oriented socket" I mean a socket created by calling
socket(2)+connect(2). This is the "client" because it is the end that
initiates the connection.

By "server oriented socket" I mean a socket created using accept(2). This
is the "server" because it is passive.

And a socket created using socket(2)+bind(2)+listen(2) does not have an
orientation because no application layer data is written to or read from
it so it is what I would call a "server socket".

Mike