Re: Using nss-pam-ldapd in a large environment, Part 2: Denial of Service due to open connections
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
Re: Using nss-pam-ldapd in a large environment, Part 2: Denial of Service due to open connections
- From: Arthur de Jong <arthur [at] arthurdejong.org>
- To: Thomas Orgis <thomas.orgis [at] uni-hamburg.de>, nss-pam-ldapd-users [at] lists.arthurdejong.org
- Subject: Re: Using nss-pam-ldapd in a large environment, Part 2: Denial of Service due to open connections
- Date: Wed, 08 Jul 2015 00:01:38 +0200
On Tue, 2015-07-07 at 21:03 +0200, Thomas Orgis wrote:
> The default number of 5 connections is another big "Why?". I really
> ask myself, and the world at large, why you need 5 channels to the
> LDAP server for NSS/PAM needs. What kind of setup is this designed
> for?
nslcd opens one connection per running thread. Each thread can process
one lookup (NSS lookup, PAM authentication, etc.) request at one time.
This was originally mostly because OpenLDAP client libraries did not
support sharing of connections across threads. nss_ldap, from which nss
-pam-ldapd was forked, had all kinds of locking constructs to work
around this limitation (with bad performance and complexity as a
result).
I think the number of 5 worker threads in nslcd came from some defaults
in nscd and some experimentation with reasonable values. You need at
least a few threads because otherwise you could deadlock some
applications (e.g. one that does a get all groups and get all users at
the same time).
You may get away with fewer threads when using nscd.
> My rescue is the design decision to have a separated daemon to begin
> with: That daemon doesn't need to run on each client!
>
> That on an intermediate server,
>
> socat TCP4-LISTEN:123,bind=a.b.c.d,reuseaddr,fork,su=nobody \
> UNIX-CLIENT:/var/run/nslcd/socket
>
> , and that on the client
>
> socat UNIX-LISTEN:/var/run/nslcd/socket \
> TCP4:a.b.c.d:123
>
> nicely forwards the requests to the centralized nslcd which pumps
> them through a reasonable set of connections.
Looks doable for some configurations. It is not really usable in
general because some functions in nslcd check whether the connecting
user is root (probably don't run socat as root).
Another option is to look into nssov. You should be able to combine it
with caching in slapd or use other replication mechanisms.
> And on the upstream front: Would it be considered to add a switch to
> make nslcd drop the connections when there are no requests to serve?
There is idle_timelimit that closes connections when they are not used.
It is disabled by default because there may be trade-offs between the
cost of setting up new connections (e.g. when using SSL) and the cost
of keeping idle connections open.
Hope this helps,
--
-- arthur - arthur@arthurdejong.org - http://arthurdejong.org/ --
--
To unsubscribe send an email to
nss-pam-ldapd-users-unsubscribe@lists.arthurdejong.org or see
http://lists.arthurdejong.org/nss-pam-ldapd-users/