* Document accounting of FDs passed over UNIX domain sockets
@ 2016-12-16 11:08 Michael Kerrisk (man-pages)
2016-12-17 7:04 ` Willy Tarreau
0 siblings, 1 reply; 3+ messages in thread
From: Michael Kerrisk (man-pages) @ 2016-12-16 11:08 UTC (permalink / raw)
To: Willy Tarreau
Cc: mtk.manpages, linux-man, lkml, socketpair, Tetsuo Handa, linux-fsdevel
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@vger.kernel.org ;-)
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/
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Document accounting of FDs passed over UNIX domain sockets
2016-12-16 11:08 Document accounting of FDs passed over UNIX domain sockets Michael Kerrisk (man-pages)
@ 2016-12-17 7:04 ` Willy Tarreau
2016-12-17 9:34 ` Michael Kerrisk (man-pages)
0 siblings, 1 reply; 3+ messages in thread
From: Willy Tarreau @ 2016-12-17 7:04 UTC (permalink / raw)
To: Michael Kerrisk (man-pages)
Cc: linux-man, lkml, socketpair, Tetsuo Handa, linux-fsdevel
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@vger.kernel.org ;-)
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Document accounting of FDs passed over UNIX domain sockets
2016-12-17 7:04 ` Willy Tarreau
@ 2016-12-17 9:34 ` Michael Kerrisk (man-pages)
0 siblings, 0 replies; 3+ messages in thread
From: Michael Kerrisk (man-pages) @ 2016-12-17 9:34 UTC (permalink / raw)
To: Willy Tarreau
Cc: mtk.manpages, linux-man, lkml, socketpair, Tetsuo Handa, linux-fsdevel
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 linux-api@vger.kernel.org ;-)
>
> 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/
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2016-12-17 9:34 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-12-16 11:08 Document accounting of FDs passed over UNIX domain sockets Michael Kerrisk (man-pages)
2016-12-17 7:04 ` Willy Tarreau
2016-12-17 9:34 ` Michael Kerrisk (man-pages)
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).