Documenting UNIX domain autobind

Documenting UNIX domain autobind

[Michael Kerrisk]

Hello Tetsuo,

I'm the Linux man-pages mainatiner. I write to you because I see that
you recently (http://kerneltrap.org/mailarchive/linux-netdev/2010/8/30/6284106/thread#mid-6284106)
did some work patchiing Linux unix_autobind(), so you may know the
answer to this question. But, also others on the CC may know.

I recently noticed this feature in the kernel, and so added some
documentation to the unix(7) man page. That text reads as follows:

   Autobind Feature
       If a bind() call specifies addrlen as  sizeof(sa_family_t),  or
       the  SO_PASSCRED  socket option was specified for a socket that
       was not explicitly bound to an  address,  then  the  socket  is
       autobound  to  an  abstract address.  The address consists of a
       null byte followed by 5 bytes in the  character  set  [0-9a-f].
       (Thus, there is a limit of 2^20 autobind addresses.)

I think this text correctly documents the technical details (but let
me know if you see errors). What is lacking is an explanation of why
this feature exists. Is someone able to explain where this feature is
used and why?

thanks,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/

Re: Documenting UNIX domain autobind

[Tetsuo Handa]

Michael Kerrisk wrote:
> I think this text correctly documents the technical details (but let
> me know if you see errors). What is lacking is an explanation of why
> this feature exists. Is someone able to explain where this feature is
> used and why?

What we can see is that unix_autobind() was added in Linux 2.1.15

  http://lxr.linux.no/linux-old+v2.1.15/net/unix/af_unix.c#L464
  addr->len = sprintf(addr->name->sun_path+1, "%08x", ordernum) + 1 + sizeof(short);

  49 * Differences from 2.0.0-11-... (ANK)
  50 *      Bug fixes and improvements.
  51 *              - client shutdown killed server socket.
  52 *              - removed all useless cli/sti pairs.
  53 *              - (suspicious!) not allow connect/send to connected not to us
  54 *                socket, return EPERM.
  55 *
  56 *      Semantic changes/extensions.
  57 *              - generic control message passing.
  58 *              - SCM_CREDENTIALS control message.
  59 *              - "Abstract" (not FS based) socket bindings.
  60 *                Abstract names are sequences of bytes (not zero terminated)
  61 *                started by 0, so that this name space does not intersect
  62 *                with BSD names.

and was changed to allow from 2^32 names to 2^20 names in Linux 2.3.15.

  http://lxr.linux.no/linux-old+v2.3.15/net/unix/af_unix.c#L514
  addr->len = sprintf(addr->name->sun_path+1, "%05x", ordernum) + 1 + sizeof(short);

I don't know the reason.

Regards.

Question on UNIX domain socket.

[Tetsuo Handa]

Hello.

Is the latest manpage for UNIX domain socket is at
http://www.kernel.org/doc/man-pages/online/pages/man7/unix.7.html ?

I got a question. Above page says

   pathname: a UNIX domain socket can be bound to a null-terminated file
   system pathname using bind(2).  When the address of the socket is returned
   by getsockname(2), getpeername(2), and accept(2), its length is
   offsetof(struct sockaddr_un, sun_path) + strlen(sun_path) + 1, and sun_path
   contains the null-terminated pathname.

However, running below program results in
"sun_path *not* containing the null-terminated pathname" (and therefore it is
not safe to use printf("%s", sun_path) even if sun_path[0] != '\0').

Should "sun_path contains the null-terminated pathname" be corrected?

Regards.

----- Test program start -----
#include <stdio.h>
#include <sys/socket.h>
#include <sys/un.h>
#include <unistd.h>

int main(int argc, char *argv[])
{
	union {
		struct sockaddr_un addr;
		char buf[512];
	} u;
	socklen_t len = sizeof(u.addr);
	int fd = socket(PF_UNIX, SOCK_STREAM, 0);
	u.addr.sun_family = AF_UNIX;
	snprintf(u.addr.sun_path, sizeof(u.buf) - 2, "/"
		 "1234567890123456789012345678901234567890"
		 "1234567890123456789012345678901234567890"
		 "1234567890123456789012345678901234567890"
		 "1234567890123456789012345678901234567890");
	if (bind(fd, (struct sockaddr *) &u.addr, sizeof(u.addr)) == EOF)
		return 1;
	memset(&u, 0, sizeof(u)); /* You may comment out this line. */
	printf("len=%d\n", len);
	if (getsockname(fd, (struct sockaddr *) &u.addr, &len) == EOF)
		return 1;
	printf("strlen=%d len=%d\n", strlen(u.addr.sun_path), len);
	return 0;
}
----- Test program end -----

----- Output of test program -----
len=110
strlen=108 len=111

Patch for man unix(7)

[Tetsuo Handa]

 From f388eedbdc0b099bb9f36ab007f9370432abb300 Mon Sep 17 00:00:00 2001
 From: Tetsuo Handa <penguin-kernel-JPay3/Yim36HaxMnTkn67Xf5DAMn2ifp@public.gmane.org>
Date: Tue, 23 Nov 2010 21:34:25 +0900
Subject: [PATCH] unix.7: Fix description of "pathname" sockets

Since unix_mkname() in net/unix/af_unix.c does

  ((char *)sunaddr)[len] = 0;

rather than

  ((char *)sunaddr)[len - 1] = 0;

, sunaddr->sun_path may not be terminated with a null byte if
len == sizeof(*sunaddr).

Therefore, the caller of getsockname(), getpeername(), accept() must not assume
that sunaddr->sun_path contains a null-terminated pathname even if the returned
addrlen is greater than sizeof(sa_family_t) and sun_path[0] != '\0'.

Signed-off-by: Tetsuo Handa <penguin-kernel-JPay3/Yim36HaxMnTkn67Xf5DAMn2ifp@public.gmane.org>
---
 man7/unix.7 |   19 ++++++++++++++++---
 1 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/man7/unix.7 b/man7/unix.7
index b53328b..7b0b47c 100644
--- a/man7/unix.7
+++ b/man7/unix.7
@@ -80,10 +80,23 @@ When the address of the socket is returned by
 and
 .BR accept (2),
 its length is
-.IR "offsetof(struct sockaddr_un, sun_path) + strlen(sun_path) + 1" ,
+.IR "offsetof(struct sockaddr_un, sun_path) + strlen(sun_path) + 1".
+Note that this length can be one byte larger than
+.IR "sizeof(struct sockaddr_un)"
+because
+.BR bind (2)
+accepts
+.IR sun_path
+which is not terminated with a null byte ('\\0').
+Therefore, you must not use string manipulation functions (e.g. strlen(),
+printf("%s")) against
+.IR sun_path
+because
+.BR getsockname (2),
+.BR getpeername (2),
 and
-.I sun_path
-contains the null-terminated pathname.
+.BR accept (2)
+may not have stored a null-terminated string.
 .IP *
 .IR unnamed :
 A stream socket that has not been bound to a pathname using
-- 
1.6.1
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Patch for man unix(7)

[Michael Kerrisk (man-pages)]

Hello Tetsuao Handa

[Thanks for the text program that you sent more recently]

On Wed, Nov 24, 2010 at 1:59 AM, Tetsuo Handa
<penguin-kernel-1yMVhJb1mP/7nzcFbJAaVXf5DAMn2ifp@public.gmane.org> wrote:
>  From f388eedbdc0b099bb9f36ab007f9370432abb300 Mon Sep 17 00:00:00 2001
>  From: Tetsuo Handa <penguin-kernel-JPay3/Yim36HaxMnTkn67Xf5DAMn2ifp@public.gmane.org>
> Date: Tue, 23 Nov 2010 21:34:25 +0900
> Subject: [PATCH] unix.7: Fix description of "pathname" sockets
>
> Since unix_mkname() in net/unix/af_unix.c does
>
>  ((char *)sunaddr)[len] = 0;
>
> rather than
>
>  ((char *)sunaddr)[len - 1] = 0;
>
> , sunaddr->sun_path may not be terminated with a null byte if
> len == sizeof(*sunaddr).
>
> Therefore, the caller of getsockname(), getpeername(), accept() must not assume
> that sunaddr->sun_path contains a null-terminated pathname even if the returned
> addrlen is greater than sizeof(sa_family_t) and sun_path[0] != '\0'.

Thanks. I see what you mean. However, I'm wondering, is the kernel
behavior simply a bug that should be fixed, so that a null terminator
is always placed in sun_path?

I realize that's an ABI change, but:
a) I suspect most sane applications would never create a sun_path that
didn't contain a null terminator within sizeof(sun_path) bytes.
b) Considering these two sets:
   1. [applications that would break if the assumption that there
         is no null terminator inside sizeof(sun_path) bytes doesn't
         hold true]
   2. [applications that would break if the kernel behavior changed]
   I suspect that set 1 is much larger than set 2.

Your thoughts?

Thanks,

Michael

> Signed-off-by: Tetsuo Handa <penguin-kernel-JPay3/Yim36HaxMnTkn67Xf5DAMn2ifp@public.gmane.org>
> ---
>  man7/unix.7 |   19 ++++++++++++++++---
>  1 files changed, 16 insertions(+), 3 deletions(-)
>
> diff --git a/man7/unix.7 b/man7/unix.7
> index b53328b..7b0b47c 100644
> --- a/man7/unix.7
> +++ b/man7/unix.7
> @@ -80,10 +80,23 @@ When the address of the socket is returned by
>  and
>  .BR accept (2),
>  its length is
> -.IR "offsetof(struct sockaddr_un, sun_path) + strlen(sun_path) + 1" ,
> +.IR "offsetof(struct sockaddr_un, sun_path) + strlen(sun_path) + 1".
> +Note that this length can be one byte larger than
> +.IR "sizeof(struct sockaddr_un)"
> +because
> +.BR bind (2)
> +accepts
> +.IR sun_path
> +which is not terminated with a null byte ('\\0').
> +Therefore, you must not use string manipulation functions (e.g. strlen(),
> +printf("%s")) against
> +.IR sun_path
> +because
> +.BR getsockname (2),
> +.BR getpeername (2),
>  and
> -.I sun_path
> -contains the null-terminated pathname.
> +.BR accept (2)
> +may not have stored a null-terminated string.
>  .IP *
>  .IR unnamed :
>  A stream socket that has not been bound to a pathname using
> --
> 1.6.1



-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Patch for man unix(7)

[Michael Kerrisk (man-pages)]

On Mon, Apr 16, 2012 at 9:42 AM, Michael Kerrisk (man-pages)
<mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Hello Tetsuao Handa
>
> [Thanks for the text program that you sent more recently]
>
> On Wed, Nov 24, 2010 at 1:59 AM, Tetsuo Handa
> <penguin-kernel-1yMVhJb1mP/7nzcFbJAaVXf5DAMn2ifp@public.gmane.org> wrote:
>>  From f388eedbdc0b099bb9f36ab007f9370432abb300 Mon Sep 17 00:00:00 2001
>>  From: Tetsuo Handa <penguin-kernel-JPay3/Yim36HaxMnTkn67Xf5DAMn2ifp@public.gmane.org>
>> Date: Tue, 23 Nov 2010 21:34:25 +0900
>> Subject: [PATCH] unix.7: Fix description of "pathname" sockets
>>
>> Since unix_mkname() in net/unix/af_unix.c does
>>
>>  ((char *)sunaddr)[len] = 0;
>>
>> rather than
>>
>>  ((char *)sunaddr)[len - 1] = 0;
>>
>> , sunaddr->sun_path may not be terminated with a null byte if
>> len == sizeof(*sunaddr).
>>
>> Therefore, the caller of getsockname(), getpeername(), accept() must not assume
>> that sunaddr->sun_path contains a null-terminated pathname even if the returned
>> addrlen is greater than sizeof(sa_family_t) and sun_path[0] != '\0'.
>
> Thanks. I see what you mean. However, I'm wondering, is the kernel
> behavior simply a bug that should be fixed, so that a null terminator
> is always placed in sun_path?
>
> I realize that's an ABI change, but:
> a) I suspect most sane applications would never create a sun_path that
> didn't contain a null terminator within sizeof(sun_path) bytes.
> b) Considering these two sets:
>   1. [applications that would break if the assumption that there
>         is no null terminator inside sizeof(sun_path) bytes doesn't

Sorry! Small thinko in previous line:

"is no null terminator" ==> "is a null terminator"

Thanks,

Michael

>         hold true]
>   2. [applications that would break if the kernel behavior changed]
>   I suspect that set 1 is much larger than set 2.
>
> Your thoughts?
>
> Thanks,
>
> Michael
>
>> Signed-off-by: Tetsuo Handa <penguin-kernel-JPay3/Yim36HaxMnTkn67Xf5DAMn2ifp@public.gmane.org>
>> ---
>>  man7/unix.7 |   19 ++++++++++++++++---
>>  1 files changed, 16 insertions(+), 3 deletions(-)
>>
>> diff --git a/man7/unix.7 b/man7/unix.7
>> index b53328b..7b0b47c 100644
>> --- a/man7/unix.7
>> +++ b/man7/unix.7
>> @@ -80,10 +80,23 @@ When the address of the socket is returned by
>>  and
>>  .BR accept (2),
>>  its length is
>> -.IR "offsetof(struct sockaddr_un, sun_path) + strlen(sun_path) + 1" ,
>> +.IR "offsetof(struct sockaddr_un, sun_path) + strlen(sun_path) + 1".
>> +Note that this length can be one byte larger than
>> +.IR "sizeof(struct sockaddr_un)"
>> +because
>> +.BR bind (2)
>> +accepts
>> +.IR sun_path
>> +which is not terminated with a null byte ('\\0').
>> +Therefore, you must not use string manipulation functions (e.g. strlen(),
>> +printf("%s")) against
>> +.IR sun_path
>> +because
>> +.BR getsockname (2),
>> +.BR getpeername (2),
>>  and
>> -.I sun_path
>> -contains the null-terminated pathname.
>> +.BR accept (2)
>> +may not have stored a null-terminated string.
>>  .IP *
>>  .IR unnamed :
>>  A stream socket that has not been bound to a pathname using
>> --
>> 1.6.1
>
>
>
> --
> Michael Kerrisk
> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
> Author of "The Linux Programming Interface"; http://man7.org/tlpi/



-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Patch for man unix(7)

[Tetsuo Handa]

Michael Kerrisk (man-pages) wrote:
> >> Therefore, the caller of getsockname(), getpeername(), accept() must not assume
> >> that sunaddr->sun_path contains a null-terminated pathname even if the returned
> >> addrlen is greater than sizeof(sa_family_t) and sun_path[0] != '\0'.
> >
> > Thanks. I see what you mean. However, I'm wondering, is the kernel
> > behavior simply a bug that should be fixed, so that a null terminator
> > is always placed in sun_path?

I thought it is a bug, but according to thread starting from
http://lkml.indiana.edu/hypermail/linux/kernel/0503.3/0954.html ,
sun_path seems to be designed to accept pathname without null terminator.

Re: Documenting UNIX domain autobind

[Michael Kerrisk (man-pages)]

Hello Tetsuo Handa,

On Sun, Oct 17, 2010 at 6:28 PM, Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
> Michael Kerrisk wrote:
>> I think this text correctly documents the technical details (but let
>> me know if you see errors). What is lacking is an explanation of why
>> this feature exists. Is someone able to explain where this feature is
>> used and why?
>
> What we can see is that unix_autobind() was added in Linux 2.1.15
>
>  http://lxr.linux.no/linux-old+v2.1.15/net/unix/af_unix.c#L464
>  addr->len = sprintf(addr->name->sun_path+1, "%08x", ordernum) + 1 + sizeof(short);
>
>  49 * Differences from 2.0.0-11-... (ANK)
>  50 *      Bug fixes and improvements.
>  51 *              - client shutdown killed server socket.
>  52 *              - removed all useless cli/sti pairs.
>  53 *              - (suspicious!) not allow connect/send to connected not to us
>  54 *                socket, return EPERM.
>  55 *
>  56 *      Semantic changes/extensions.
>  57 *              - generic control message passing.
>  58 *              - SCM_CREDENTIALS control message.
>  59 *              - "Abstract" (not FS based) socket bindings.
>  60 *                Abstract names are sequences of bytes (not zero terminated)
>  61 *                started by 0, so that this name space does not intersect
>  62 *                with BSD names.
>
> and was changed to allow from 2^32 names to 2^20 names in Linux 2.3.15.
>
>  http://lxr.linux.no/linux-old+v2.3.15/net/unix/af_unix.c#L514
>  addr->len = sprintf(addr->name->sun_path+1, "%05x", ordernum) + 1 + sizeof(short);
>
> I don't know the reason.

Long after the fact, I added text to unix(7) to note the change in the
size of the namespace you noted above.

However, the unix(7) man page still lacks an explanation of the
purpose of the autobind feature. Can anyone help?

Thanks,

Michael



-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/