Re: [patch] Fix handling of overlength pathname in AF_UNIX sun_path

On Thu, Apr 19, 2012 at 10:19 PM, Alan Cox [off-list ref] wrote:

quoted

3. Considering these two sets:

  (a) [applications that rely on the assumption that there
       is a null terminator inside sizeof(sun_path) bytes]
  (b) [applications that would break if the kernel behavior changed]

  I suspect that set (a) is rather larger than set (b)--or, more
  likely still, applications ensure they go for the lowest common
  denominator limit of 92 (HP-UX) or 104 (historical BSD limit)
  bytes, and so avoid this issue completely.

Or another way of putting it

3(a)    Sloppy coding that may have lots of other bugs

3(b)    Interfaces and code we promised not to break.

Yes, it's another way of putting it. (Though regarding 3(b), part of
the problem is that there never was a clearly specified contract.)

Anyway, I've dug deeper, looking at hat happens on other platforms.
It's a mess: the BSDs don't even guarantee  that sun_path is
null_terminated. So, here's how one has to portably deal with the
variations:

addrlen = sizeof(struct sockaddr_un);
cfd = accept(lfd, &addr, &addlen);

printf("%.*s", addrlen - offsetof(struct sockaddr_un, sun_path), addr.sun_path);

That's pretty hideous!

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/