[PATCH] winbindd: control number of winbindd's client connections

Uri Simchoni urisimchoni at gmail.com
Mon Jun 8 13:25:53 MDT 2015

I'll try what you suggest. I tried documenting my understanding in
comments inside.


On Mon, Jun 8, 2015 at 12:13 PM, Volker Lendecke
<Volker.Lendecke at sernet.de> wrote:
> Sorry to be a bit late in the game, I was too busy to really give the
> issue some thought last week.
> How about the following approach to solve the problem:
> Every time we are about to ship some request to a winbind child we could
> to check whether the corresponding winbind client is still around. I
> know that this means that we need to carry state information down to
> some deep levels. The information about which client is being served is
> not readily available in wb_child_request_trigger, but I'm sure there's
> ways to get it there.
> We can even go one step further and keep listening for readability on
> the client socket while a request is in progress, waiting for its turn
> down to the child process. While a child RPC request is in progress,
> we need to stop listening for the client disconnect, as this would badly
> destroy the parent->child protocol sequence.
> If that is done, isn't most of the problem already solved?  If we are
> running into fd limits, just bump up the number of fds. Fds are relatively
> cheap these days, in particular if with modern winbind you're using
> epoll. 3.3.16 won't have that yet, but master should.  Also, there can
> be at most one fd per system thread assuming normal use of libwbclient.

It has taken me a while to figure out this one. What I understand is
"don't bother with stopping and resuming accept, just set winbind max
clients to something high enough, and bump the max FDs accordingly.
Even if you don't know what high enough is, you can set it to
something really really high because winbindd's ability to accept
clients (with epoll) exceeds the system's ability to create clients
(with fork - 1 fd per process, assuming client is not malicious and
well behaved)" That, assuming we keep the number of accepted
connections equal to the number of clients, and we do that by checking
whether the client is still there.

In that case I would also change (fix) the documentation of "winbind
max clients" - it is not a limit but more of a hint.

What if the client is not well-behaved? I suppose we can attack the
problem of malicious clients by passing the client's pid via the unix
domain socket and keeping a map that enforces the one connection per
client rule - that's outside the scope of this patch set as this
possibility existed before.

> Regarding the "did some real work" issue: Yes, I can see value in it. But
> as those requests do no blocking, do we really kill those clients very
> often? My gut feeling is that these connections are very quick, and
> if we kill idle clients based on a LRU scheme, will we ever hit those
> PRIV_SOCKET request clients?
I understand what you're saying. I suppose I envisioned a situation
where lots of clients open new connections simultaneously, winbindd
hits the limit and then just keeps shutting down connections without
really having done anything useful. It can easily be simulated but I
have no evidence it is a real-world situation. Come to think of it,
even if the network becomes unavailable and all smb connections
dropped, when it is back the connections will be reopened due to user
activity, i.e. not all at once. The patch can be dropped.

> I know those changes might be larger, but I'm a bit reluctant to make
> winbind stop accepting connections.  winbind is really central, and
> stopping to accept connections might even have security implications.

More information about the samba-technical mailing list