Hi Michael,
On Fri, Dec 16, 2016 at 12:08:33PM +0100, Michael Kerrisk (man-pages) wrote:
> Hello Willy,
>
> Your commit 712f4aad406bb1 ("unix: properly account for FDs passed over
> unix sockets" added accounting to ensure that the RLIMIT_NOFILE limit
> could not be bypassed when passing file descriptors across UNIX
> domain sockets.
>
> Such patches should be CCed to linux-api@xxxxxxxxxxxxxxx ;-)
Yes, I learned this after your presentation at kernel recipes, but this
patch pre-dates it ;-)
> A documentation [atch would be great as well, but I had a shot
> at cobbling some text together. Does the text below (for the unix(7)
> man page) look okay?
I think so, though maybe we can arrange it very slightly given that
this was considered as a fix for a vulnerability and backported to
various kernels :
> ETOOMANYREFS
> This error can occur for sendmsg(2) when sending a file
> descriptor as ancilary data over a UNIX domain socket (see
> the description of SCM_RIGHTS, above). It occurs if the
> number of "in-flight" file descriptors exceeds the
> RLIMIT_NOFILE resource limit and the caller does not have
> the CAP_SYS_RESOURCE capability. An in-flight file
> descriptor is one that has been sent using sendmsg(2) but
> has not yet been accepted in the recipient process using
> recvmsg(2).
>
> This error is diagnosed since Linux 4.5. In earlier kernel
> versions, it was possible to place an unlimited number of
> file descriptors in flight, by sending each file descriptor
> with sendmsg(2) and then closing the file descriptor so
> that it was not accounted against the RLIMIT_NOFILE
> resource limit.
- resource limit.
+ resource limit. Some older stable kernels might have
+ included the same check by backporting the fix from 4.5.
I've just checked the exact versions containing this, but I don't think
it's worth providing the list, in my opinion mentionning that it could be
observed on some older versions is enough to help developers who see it
in field :
- 3.2.78
- 3.10.99
- 3.12.57
- 3.14.63
- 3.16.35
- 3.18.27
- 4.1.19
- 4.4.4
Best regards,
Willy
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
