Re: [PATCH] unix: properly account for FDs passed over unix sockets

2016-01-04 Thread David Miller
From: Willy Tarreau Date: Mon, 28 Dec 2015 15:14:35 +0100 > It is possible for a process to allocate and accumulate far more FDs than > the process' limit by sending them over a unix socket then closing them > to keep the process' fd count low. > > This change addresses this

Re: [PATCH] unix: properly account for FDs passed over unix sockets

2015-12-31 Thread One Thousand Gnomes
On Thu, 31 Dec 2015 08:12:53 +0100 Willy Tarreau wrote: > On Thu, Dec 31, 2015 at 03:08:53PM +0900, Tetsuo Handa wrote: > > Willy Tarreau wrote: > > > On Wed, Dec 30, 2015 at 09:58:42AM +0100, Hannes Frederic Sowa wrote: > > > > The MSG_PEEK code should not be harmful and the patch

Re: [PATCH] unix: properly account for FDs passed over unix sockets

2015-12-30 Thread Tetsuo Handa
Willy Tarreau wrote: > On Wed, Dec 30, 2015 at 09:58:42AM +0100, Hannes Frederic Sowa wrote: > > The MSG_PEEK code should not be harmful and the patch is good as is. I > > first understood from the published private thread, that it is possible > > for a program to exceed the rlimit of fds. But

Re: [PATCH] unix: properly account for FDs passed over unix sockets

2015-12-30 Thread Willy Tarreau
On Thu, Dec 31, 2015 at 03:08:53PM +0900, Tetsuo Handa wrote: > Willy Tarreau wrote: > > On Wed, Dec 30, 2015 at 09:58:42AM +0100, Hannes Frederic Sowa wrote: > > > The MSG_PEEK code should not be harmful and the patch is good as is. I > > > first understood from the published private thread,

Re: [PATCH] unix: properly account for FDs passed over unix sockets

2015-12-30 Thread Willy Tarreau
On Wed, Dec 30, 2015 at 09:58:42AM +0100, Hannes Frederic Sowa wrote: > The MSG_PEEK code should not be harmful and the patch is good as is. I > first understood from the published private thread, that it is possible > for a program to exceed the rlimit of fds. But the DoS is only by > keeping

Re: [PATCH] unix: properly account for FDs passed over unix sockets

2015-12-30 Thread Hannes Frederic Sowa
On 29.12.2015 21:35, Willy Tarreau wrote: On Tue, Dec 29, 2015 at 03:48:45PM +0100, Hannes Frederic Sowa wrote: On 28.12.2015 15:14, Willy Tarreau wrote: It is possible for a process to allocate and accumulate far more FDs than the process' limit by sending them over a unix socket then closing

Re: [PATCH] unix: properly account for FDs passed over unix sockets

2015-12-30 Thread One Thousand Gnomes
> > Another idea would be to add the amount of memory used to manage the fds > > to sock_rmem/wmem but I don't see any advantages or disadvantages. > > Compared to the impact of the pending data in pipes themselves in flight, > this would remain fairly minimal. The true size of the memory

Re: [PATCH] unix: properly account for FDs passed over unix sockets

2015-12-29 Thread Willy Tarreau
On Tue, Dec 29, 2015 at 03:48:45PM +0100, Hannes Frederic Sowa wrote: > On 28.12.2015 15:14, Willy Tarreau wrote: > >It is possible for a process to allocate and accumulate far more FDs than > >the process' limit by sending them over a unix socket then closing them > >to keep the process' fd count

Re: [PATCH] unix: properly account for FDs passed over unix sockets

2015-12-29 Thread Hannes Frederic Sowa
On 28.12.2015 15:14, Willy Tarreau wrote: It is possible for a process to allocate and accumulate far more FDs than the process' limit by sending them over a unix socket then closing them to keep the process' fd count low. This change addresses this problem by keeping track of the number of FDs

Re: [PATCH] unix: properly account for FDs passed over unix sockets

2015-12-29 Thread Hannes Frederic Sowa
On 28.12.2015 15:14, Willy Tarreau wrote: @@ -1528,10 +1546,8 @@ static int unix_attach_fds(struct scm_cookie *scm, struct sk_buff *skb) if (!UNIXCB(skb).fp) return -ENOMEM; - if (unix_sock_count) { - for (i = scm->fp->count - 1; i >= 0; i--) -

[PATCH] unix: properly account for FDs passed over unix sockets

2015-12-28 Thread Willy Tarreau
It is possible for a process to allocate and accumulate far more FDs than the process' limit by sending them over a unix socket then closing them to keep the process' fd count low. This change addresses this problem by keeping track of the number of FDs in flight per user and preventing