netdev - Re: [PATCH net-next] af_unix: preserve position of fd-associated bytes in stream

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <20190408.162148.1372227737485369725.davem@davemloft.net>
Date:   Mon, 08 Apr 2019 16:21:48 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     chris@...san.to
Cc:     netdev@...r.kernel.org
Subject: Re: [PATCH net-next] af_unix: preserve position of fd-associated
 bytes in stream

From: Christopher Monsanto <chris@...san.to>
Date: Sat,  6 Apr 2019 12:33:25 -0400

> It is currently impossible for the reader of an AF_UNIX stream socket to
> fully reconstruct the data sent in the presence of SCM_RIGHTS, without
> reading byte-for-byte. This prevents efficiently proxying or providing a
> high-level buffering interface to these sockets.
> 
> Unfortunately POSIX does not specify the behavior of SCM_RIGHTS beyond the
> existence of the constant and in general the semantics of ancillary data
> attached to streams isn't on the firmest ground. The following is how these
> concepts work on every *nix I am aware of. An SCM_RIGHTS array of file
> descriptors is uniquely associated with a single byte in the stream; this
> byte can be identified by reading the stream one byte at a time. sendmsg()
> associates the given fds with the first byte in the buffer provided. When
> recvmsg() returns fds, we know that exactly one fd-associated byte appears
> in the buffer; if necessary partial reads are employed to guarantee this
> invariant.
> 
> The issue in question concerns recvmsg(). Linux allows the fd-associated
> byte to appear anywhere within the buffer; the reader has no way of knowing
> which one it is. Other *nix systems (at least macOS/Solaris/FreeBSD), make
> recvmsg() symmetric with sendmsg() and guarantee that the fd-associated
> byte is the first byte in the buffer. The first change of this patch has
> Linux adopt the stronger semantics of its peers, which fixes the issue at
> hand while also bringing us closer to standardizing SCM_RIGHTS.
> 
> The existing implementation enforces the one-fd-associated-byte constraint
> with a partial read after any skb with attached fds. The second & third
> changes remove this unnecessary constraint, allowing data from subsequent
> skbs to be copied to the buffer, as long those skbs do not have fds
> attached to them.
> 
> Signed-off-by: Christopher Monsanto <chris@...san.to>

No app can ever, really ever, really universally depend upon this
behavior.

I really have a hard time accepting that we should change something
semantically on this level moving forward, which has lasted more than
2 decades.