LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Michael Kerrisk <mtk.manpages@googlemail.com>
To: samuel.thibault@ens-lyon.org
Cc: David Miller <davem@davemloft.net>,
mtk.manpages@googlemail.com, andi@firstfloor.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH,TRIVIAL] AF_UNIX, accept() and addrlen
Date: Mon, 12 May 2008 15:10:04 +0200 [thread overview]
Message-ID: <482841AC.4020609@gmail.com> (raw)
In-Reply-To: <20080426.225432.128575953.davem@davemloft.net>
Samuel, et al.
David Miller wrote:
> From: Samuel Thibault <samuel.thibault@ens-lyon.org>
> Date: Sat, 26 Apr 2008 02:44:45 +0100
>
>> AF_UNIX: make unix_getname use sizeof(sunaddr->sun_family) instead of
>> sizeof(short).
>>
>> Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
>
> This is just syntactic masterbation, sa_family_t is typedef'd
> "unsigned short".
>
> No system on planet earth providing the BSD sockets API uses
> anything other than uint16_t or unsigned short for this.
>
> Sorry, I'm not applying this.
I finally got round to testing on FreeBSD. Linux and BSD are unfortunately not
compatible. For the unnamed sockets, FreeBSD says the socket address length is
16 bytes (whereas Linux says it's 2 bytes). On the other hand, there doesn't
seem to be much consistency across implementations: HP-UX's get{peer,sock}name()
says that unnamed sockets have a zero-length address.
Anyway, the situation we have is three address formats in the Unix domain on Linux:
Named sockets (socket was given an string name with bind())
length >= 4 (i.e., sizeof(unsigned short) + at least one character for a
pathname + 1 for the NUL
sun_path is a null-terminated string
Abstract sockets (socket was bound to a sun_path whose initial byte is 0)
Length == sizeof(struct sockaddr_un) (i.e., 110)
sun_path is an initial null byte, followed by 107 other bytes that make the name
unique
Unnamed sockets (created by socketpair(), or when we connect() a socket that was
not bound to a name; the current unix.7 page suggests that when we connect() a
socket that was not bound, then it gets a name in the abstract name space --
that's not true)
Length = 2
sun_path is 108 null bytes .
I have drafted a revision to section of the unix.7 page describing the address
format to try and cover all of the above. Samuel (and David?) could you review
please?
Cheers,
Michael
Address Format
A Unix domain socket address is represented in the following
structure:
#define UNIX_PATH_MAX 108
struct sockaddr_un {
sa_family_t sun_family; /* AF_UNIX */
char sun_path[UNIX_PATH_MAX]; /* pathname */
};
sun_family always contains AF_UNIX.
Three types of address are distinguished in this structure:
* pathname: a Unix domain socket can be bound to a null-ter-
minated file system pathname using bind(2). When the
address of the socket is returned by getsockname(2), get-
peername(2), and accept(2), its length is sizeof(sa_fam-
ily_t) + strlen(sun_path) + 1, and sun_path contains the
null-terminated pathname.
* anonymous: A stream socket that is connect(2)ed to another
socket without first being bound to an address is anony-
mous. Likewise, the two sockets created by socketpair(2)
are anonymous. When the address of an anonymous socket is
returned by getsockname(2), getpeername(2), and accept(2),
its length is sizeof(sa_family_t), and sun_path should not
be inspected.
* abstract: an abstract socket address is distinguished by
the fact that sun_path[0] is a null byte (`\0'). All of
the remaining bytes in sun_path define the "name" of the
socket. (Null bytes in the name have no special signifi-
cance.) The name has no connection with file system path-
names. The socket's address in this namespace is given by
the rest of the bytes in sun_path. When the address of an
abstract socket is returned by getsockname(2), getpeer-
name(2), and accept(2), its length is sizeof(struct sock-
addr_un), and sun_path contains the abstract name. The
abstract socket namespace is a non-portable Linux exten-
sion.
== END ==
next prev parent reply other threads:[~2008-05-12 13:10 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-08 2:23 [PATCH,TRIVIAL] AF_UNIX, accept() and addrlen Samuel Thibault
2008-03-24 4:56 ` David Miller
2008-03-24 10:43 ` Samuel Thibault
2008-03-24 11:50 ` Andi Kleen
2008-03-24 12:17 ` Samuel Thibault
2008-03-24 12:27 ` Samuel Thibault
2008-03-31 4:00 ` Michael Kerrisk
2008-03-31 9:44 ` Samuel Thibault
2008-03-31 18:51 ` Michael Kerrisk
2008-04-18 16:52 ` Michael Kerrisk
2008-04-24 0:16 ` Samuel Thibault
2008-04-24 8:31 ` Michael Kerrisk
2008-04-26 1:44 ` Samuel Thibault
2008-04-27 5:54 ` David Miller
2008-05-12 13:10 ` Michael Kerrisk [this message]
2008-05-12 13:20 ` Samuel Thibault
2008-03-24 20:23 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=482841AC.4020609@gmail.com \
--to=mtk.manpages@googlemail.com \
--cc=andi@firstfloor.org \
--cc=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--cc=samuel.thibault@ens-lyon.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).