[PATCH 0/3] UNIX sockets: POSIX conformance of errno's

[PATCH 0/3] UNIX sockets: POSIX conformance of errno's

[Ed Schouten]

Hi there,

While comparing the behavior of the Berkeley sockets API different
operating systems, I noticed that in some places we return different
errno's as what POSIX requires and how other systems work, but also what
we document in our own man pages.

This is the first time I'm sending a patch to the Linux kernel, so if
there's anything wrong with the way I submitted these patches, just let
me know.

Thanks,
Ed

Ed Schouten (3):
  Make listen() on an unbound UNIX socket return EDESTADDRREQ.
  Let open() on a UNIX socket return EOPNOTSUPP.
  Return ENOTCONN when trying to recv() on an unconnected UNIX socket.

 fs/inode.c         | 13 ++++++++++++-
 net/unix/af_unix.c |  6 +++---
 2 files changed, 15 insertions(+), 4 deletions(-)

-- 
2.5.0

Re: [PATCH 0/3] UNIX sockets: POSIX conformance of errno's

[David Miller]

From: Ed Schouten <ed@nuxi.nl>
Date: Thu,  3 Mar 2016 12:23:36 +0100

> Hi there,
> 
> While comparing the behavior of the Berkeley sockets API different
> operating systems, I noticed that in some places we return different
> errno's as what POSIX requires and how other systems work, but also what
> we document in our own man pages.
> 
> This is the first time I'm sending a patch to the Linux kernel, so if
> there's anything wrong with the way I submitted these patches, just let
> me know.

I see very little to no value, if not harm, in doing this.

We've returned errors this way for two decades, and if there is code
out there checking the existing error codes it will break.

I really dislike blind POSIX/BSD/etc. "compliance" patches like this
because it completely ignores the decades of precedence our current
behavior has, upon which application might depend upon.

I'm not applying this series, sorry.

Re: [PATCH 0/3] UNIX sockets: POSIX conformance of errno's

[Guy Harris]

On Mar 3, 2016, at 3:23 AM, Ed Schouten <ed@nuxi.nl> wrote:

> While comparing the behavior of the Berkeley sockets API different
> operating systems, I noticed that in some places we return different
> errno's as what POSIX requires and how other systems work, but also what
> we document in our own man pages.
> 
> This is the first time I'm sending a patch to the Linux kernel, so if
> there's anything wrong with the way I submitted these patches,

Well, there doesn't actually seem to be any patches attached to the message, so that might be one thing that's wrong with it, unless it somehow got lost between you and me.  That's why, in my comments, I'm saying "if" in a number of places - I don't know what changes are being made.

> just let me know.
> 
> Thanks,
> Ed
> 
> Ed Schouten (3):
>  Make listen() on an unbound UNIX socket return EDESTADDRREQ.

The current version of the Single UNIX Specification says, on the page for listen():

	[EDESTADDRREQ]
		The socket is not bound to a local address, and the protocol does not support listening on an unbound socket.

The Linux man page for listen() doesn't say anything about listening on an unbound socket.  A quick look at the kernel code in Git seems to indicate that it returns EINVAL, so maybe a case could be made for changing it.

>  Let open() on a UNIX socket return EOPNOTSUPP.

The current version of the Single UNIX Specification appears to be silent, in the page for open(), on what happens if you hand open() a pathname for a UNIX-domain socket file, so, whilst Linux may incompatible with some other systems here, it's not incompatible with what POSIX requires.

In addition, I see nothing about UNIX-domain socket opens on the Linux open() man page:

	http://man7.org/linux/man-pages/man2/open.2.html

>  Return ENOTCONN when trying to recv() on an unconnected UNIX socket.

The current version of the Single UNIX Specification says, on the page for recv():

	[ENOTCONN]
		A receive is attempted on a connection-mode socket that is not connected.

A quick look at the current kernel code in Git indicates that it would return EINVAL instead, although it'd return ENOTCONN for sequenced-packet sockets, so maybe a case could be made for changing it.

So I see one case (open()) where there doesn't seem to be any case for the change, and two cases where a case could be made.

However, as Linux doesn't claim to be a UNIX(R), it's not as if violating the POSIX spec is *ipso facto* a problem - and "[Linux's] own man pages" appear to be silent on those issues. If, as David notes, there's the risk of breaking apps if the change is made, just as there's the risk of breaking apps ported from other platforms if the change *isn't* made.

I don't know of any data to indicate what would break in either case, so conservatism, i.e. not changing Linux's behavior, might be the right choice.  (From a pure abstract principle point of view, I'd vote for the change, but sometimes things work better if you ignore abstract principles.)