Re: [PATCH,TRIVIAL] AF_UNIX, accept() and addrlen

["Michael Kerrisk" <mtk.manpages@gmail.com>]

Samuel,

It would really be much more useful if you CCed me, rather than hoping
that I'd find this patch by trawling LKML...

David, Andi,

My understanding about abstract namespace sockets (what Samuel calls
unnamed sockets) is that the indicator that the address is for an
unnamed socket is that the sun_path starts with a zero byte -- and the
*entire* remainder of the sun_path constitutes the name of the socket.
 As such, information about the size returned by accept() etc. is
redundant. (I've happily written programs that use abstract namespace
sockets without even knowing what is returned by a succesful
accept().)

I agree with Samuel that there should be some documentation of the
return value of accept() etc, for abstract sockets but my inclination
would be to document that the indicator that this is an abstract
socket is the initial null byte in sun_path, and mention the returned
length as an after word.  Does this seem reasonable?

Cheers,

Michael

On 3/24/08, Samuel Thibault <samuel.thibault@ens-lyon.org> wrote:
> Samuel Thibault, le Mon 24 Mar 2008 12:17:19 +0000, a écrit :
>
> > Andi Kleen, le Mon 24 Mar 2008 12:50:10 +0100, a écrit :
>  > > Samuel Thibault <samuel.thibault@ens-lyon.org> writes:
>  > > > David Miller, le Sun 23 Mar 2008 21:56:41 -0700, a écrit :
>  > > > > From: Samuel Thibault <samuel.thibault@ens-lyon.org>
>  > > > > Date: Sat, 8 Mar 2008 02:23:21 +0000
>  > > > >
>  > > > > > Accept and getpeername are supposed to return the amount of bytes
>  > > > > > written in the returned address.  However, on unnamed sockets, only
>  > > > > > sizeof(short) is returned, while a 0 is put in the sun_path member.
>  > > > > > This patch adds 1 for that additional byte.
>  > > > > >
>  > > > > > Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
>  > > > >
>  > > > > This change isn't correct.  It's the fact that the
>  > > > > length returned is sizeof(short) that tells the caller
>  > > > > that the unix socket is unnamed.
>  > > >
>  > > > Mmm, where that is documented?
>  > > >
>  > > > I can't find any details about that in SUS, and man 7 unix says
>  > > >
>  > > > `If sun_path starts with a null byte ('' '), then it refers to the
>  > > > abstract namespace main- tained by the Unix protocol module.'
>  > >
>  > > [I wrote unix(7) originally]. The abstract name space is a Linux
>  > > extension and there is no written standard and whatever the kernel
>  > > implements is the de-facto standard. If unix(7) differs in anything
>  > > from what the code does please send patches to the manpages
>  > > maintainer.
>  >
>  > Oops, sorry, we are not talking about abstract namespace actually (their
>  > sockaddr length are necessarily bigger than sizeof(sa_family_t) since
>  > they need some data), but unamed sockets.  So the Address Format
>  > paragraph just misses description of unnamed sockets.
>
>
> How about this?
>
>  --- unix.7.orig 2008-03-24 12:24:37.000000000 +0000
>  +++ unix.7      2008-03-24 12:24:56.000000000 +0000
>  @@ -87,6 +87,15 @@
>   bytes in
>   .IR sun_path .
>   Note that names in the abstract namespace are not zero-terminated.
>  +If the size returned by
>  +.BR accept
>  +or
>  +.BR getpeername
>  +is
>  +.IR sizeof(sa_family_t) ,
>  +then it refers to a unnamed socket and
>  +.I sun_path
>  +should not be read.
>   .SS Socket Options
>   For historical reasons these socket options are specified with a
>   .B SOL_SOCKET
>
>
>  Samuel
>  --
>  To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>  the body of a message to majordomo@vger.kernel.org
>  More majordomo info at  http://vger.kernel.org/majordomo-info.html
>  Please read the FAQ at  http://www.tux.org/lkml/
>


-- 
I'll likely only see replies if they are CCed to mtk.manpages at gmail dot com