DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=wOGEekkH8p+5ceV+y0FbWpsSz8pAEahBCUnbe/9NEYNpkcPpJi5Iy
	/l9RN0MDjxBNlk3e9YWmf0vToq+E25EKYV/dggdLcPvRYk2s2dXRc6vWzrpj2rsy
	vvRd+ISM/5tyYwPYfV9Wn/nVLSzseAIFMAyi0KzUHjdbIoAbFNwKKE=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Date: Tue, 17 Jun 2014 12:00:11 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: timeout in LDAP access
Message-ID: <20140617100011.GL23700@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <F312783D-AD66-4614-922B-E44403C7E372 AT Denis-Excoffier DOT org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;	protocol="application/pgp-signature"; boundary="jQIvE3yXcK9X9HBh"
Content-Disposition: inline
In-Reply-To: <F312783D-AD66-4614-922B-E44403C7E372@Denis-Excoffier.org>
User-Agent: Mutt/1.5.23 (2014-03-12)

--jQIvE3yXcK9X9HBh
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi Denis,

On Jun 16 22:39, Denis Excoffier wrote:
> Hello,
>=20
> I=E2=80=99ve exercised =E2=80=98getent' a little bit those days (with 'db=
_enum: all=E2=80=99
> in /etc/nsswitch.conf), and it seems to me that the timeout =E2=80=98tv' =
(3
> seconds, in ldap.cc) is probably too small for servers not so quickly
> responsive or with many (500000, fake or real) users around (see the
> call to ldap_get_next_page_s()). 300 seconds should be enough i
> suppose.

300 seconds is a lot.  I'm not quite sure I'm following you here.  Let
me start by explaining how the timeout is applied so we're all on the
same page.

When opening the conection to the DC, the bind operatrion will wait
3 seconds for the bind operation to complete.

In calls to getpwnam, getpwuid, getgrname, getgrgid, the 3 seconds
timeout is the timeout for fetching a single user or group entry.  And
it's not the timeout for fetching the basic info (name<->SID mapping),
but only the timeout for the LDAP call returning the extended user info
(pgid, gecos, home, shell).  So, typically the user<->uid mapping is
correct, only the secondary info might be wrong, if it's set in AD at
all.

When enumerating accounts (getpwent, getgrent) the timeout is applied to
every call fetching the next 100 accounts.  The *only* information which
is actually enumerated is the list of existing SIDs, with a timeout of
3 seconds per 100 SIDs.  So it's taking more than 3 seconds to fetch
100 account SIDs?  And then...

> Also it is a pity that LDAP_TIMEOUT is not announced to the user
> (except under strace: 0x55). I don=E2=80=99t know the general policy for
> timeouts, but i consider that the user would like to be informed when
> the passwd/group list was truncated.

...you really get an LDAP_TIMEOUT from ldap_get_next_page_s?  This
puzzels me a bit since the documentation implies that tyhis won't
happen.  Here's the snippet from MSDN:

  When parsing the results set, it is possible for the server to return
  an empty page of results and yet still respond with an LDAP_SUCCESS
  return code. This indicates that the server was unable to retrieve a
  page of results, due to a timeout or other reason, but has not
  completed the search request. The proper behavior in this instance is
  to continue to call ldap_get_next_page_s until either another page of
  results are successfully retrieved, an error code is returned, or
  LDAP_NO_RESULTS_RETURNED is returned to indicate the search is
  complete.

So I expect an LDAP_SUCCESS with ldap_count_entries() =3D=3D 0 and then
repeat the request.  But the code doesn't expect LDAP_TIMEOUT in this
case.  Do I have to handle LDAP_TIMEOUT here as well?

As far as propagating the timeout to the user, that's kind of tricky.
I'm not looking forward to do that, but if so, it could only be an EIO
error returned from get{pw,gr}ent.

The general problem with timeouts is that they are always wrong.

I'm wondering if the timeout, at least for enumerating accounts, should
go away entirely.  In case of a connection problem this could result in
a hang for about 2 minutes by default I think (LDAP_OPT_PING_LIMIT).

I could also raise the timeout, but the value doesn't really matter, it
will be just as wrong as 3 seconds, just differently.

Thoughts?

> Another (unrelated and less important) problem is that 'getent'
> happily produces lines with some extra =E2=80=98:=E2=80=99, in particular=
 when the
> gecos field itself contains =E2=80=98:=E2=80=99.

Wow, that *is* important.  All fields returned from the server have to
get their colons converted to commas.  I'll fix that.


Thanks,
Corinna

--=20
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--jQIvE3yXcK9X9HBh
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJToBGrAAoJEPU2Bp2uRE+gzasQAIGPXxptq0AMFLLvMFuRDzPX
6FVz2gg9+/J3IIT7nhD+IZfXBRRvUlTjV56cuOftRjd3yIrejLbivKTCyNtXAZ9Y
mov0LRMFummA51pUcQEaCPPLy88+PPkp/V5MYzC7lTu7/AWgjxmbYxMWnHEibozY
mLPJ2grDvXG7i46pkJsS0LnsZUMs5REOlS36/uXoypvtWQ+xW0rGvuVng5HN56pI
aJpXzaezoZKi3b13Xiagy8v2Dsekcg2jkQu6bymHrqotqn+3Ez7A/qGVsfjT7bEj
L8kOe9nnLPprTThpRXCCIOvKFidGtK6H0YV/fpRsFGKUGwr8gBLQr2wlIYSDz32L
nn7XmtWzFzkT3/UOIXS+9E+ZLePHDbRlh+RaIM6ZPIhHCW/rTjYydXrtpQQRNf2p
QOLvD5RwHA75YrLriXXajhJAIGDIOe9HguGWBXMIpvgZAX92Jh5NKzpfMwCAkMlH
OEVbluFNyCHNh3t9JC0hXMAI1yg+A0n2ncZuXiBfwZZykToFOWXtZgOGZUmcE6Mf
he/bJTMyRzt6KDDAGhleuTr3O5w9rzE8UPO56jEiTwQckYLHrGz0ZUrq78AOOwRO
c2gQTt8NVZ0hn/X2KQWQqgkhy3Yd3sQ3mHoY72NBF9HxX4wWllV+SkSsurzK9kiv
XXOwnnHqSzrvztpviuvZ
=FyDs
-----END PGP SIGNATURE-----

--jQIvE3yXcK9X9HBh--