linux-kernel - Re: Document accounting of FDs passed over UNIX domain sockets

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] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 17 Dec 2016 08:04:31 +0100
From:   Willy Tarreau <w@....eu>
To:     "Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
Cc:     linux-man <linux-man@...r.kernel.org>,
        lkml <linux-kernel@...r.kernel.org>, socketpair@...il.com,
        Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
        linux-fsdevel@...r.kernel.org
Subject: Re: Document accounting of FDs passed over UNIX domain sockets

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@...r.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