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 [email protected] ;-)
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?
Cheers,
Michael
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.
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
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 [email protected] ;-)
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
Hi Willy,
On 12/17/2016 08:04 AM, Willy Tarreau wrote:
> 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 [email protected] ;-)
>
> Yes, I learned this after your presentation at kernel recipes, but this
> patch pre-dates it ;-)
But the note in Documentation/SubmittingPatches predates that ;-)
>> 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
Yea. This is a tricky issue that I run into now and then. I've added
some different wording that expresses they same idea you intended.
Thanks for noting this.
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/