X-Recipient: archive-cygwin AT delorie DOT com
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=eAJ5rcWEpyfgeCYKyFv5vL7i59tbId+K8utAPEtCbfxXi+D/lbSv8
	hR737zrshFq8S2oXyIAgIYEVu4pCU6kPjz8a1mvuvRKgY26fGY70J7JMMKOnB+pR
	rIUqNb7ZncHSYj0vxYqsV28rl8vCl+HTgi3k3KB4Mk75Ph29/XtBzs=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; 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; s=default;
	 bh=vVKPIfPvKvlmMuGeskudq1RtI6U=; b=y1ZO1Q3KZ1BxnJYCz5/X9AHZBu/Z
	meJEpkz8jw9BZ3NbA3UtJo2vMBlO0ghr2/sBSxVrpUL5kT1xzTzKA1lcsJ3YfsSO
	WxWxO28e4PFkuGX/2J0smeYgzYVli6IbIJEUbhrFoxlhglCxy/BjiGWhYdGRZ8uL
	URJuO2qjpcvVCN4=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-6.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2
X-HELO: calimero.vinschen.de
Date: Thu, 13 Feb 2014 15:44:19 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: get rid of getpwent? (Was: cygwin-1.7.28 getpwent header declaration changes ?)
Message-ID: <20140213144419.GI2246@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <4510121021 DOT 20140211062515 AT mtu-net DOT ru> <52FAB14C DOT 8060800 AT tiscali DOT co DOT uk> <52FABAF5 DOT 2060701 AT etr-usa DOT com> <52FAD730 DOT 9090507 AT redhat DOT com> <20140212090804 DOT GM2821 AT calimero DOT vinschen DOT de> <52FB9E51 DOT 7030607 AT cornell DOT edu> <20140212195931 DOT GA2246 AT calimero DOT vinschen DOT de> <20140212213729 DOT GA5589 AT ednor DOT casa DOT cgf DOT cx> <20140213100025 DOT GB24159 AT calimero DOT vinschen DOT de> <20140213143541 DOT GC6750 AT ednor DOT casa DOT cgf DOT cx>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;	protocol="application/pgp-signature"; boundary="tctmm6wHVGT/P6vA"
Content-Disposition: inline
In-Reply-To: <20140213143541.GC6750@ednor.casa.cgf.cx>
User-Agent: Mutt/1.5.21 (2010-09-15)

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

On Feb 13 09:35, Christopher Faylor wrote:
> On Thu, Feb 13, 2014 at 11:00:25AM +0100, Corinna Vinschen wrote:
> >On Feb 12 16:37, Christopher Faylor wrote:
> >> On Wed, Feb 12, 2014 at 08:59:31PM +0100, Corinna Vinschen wrote:
> >> >There's only one tiny problem.  Whatever I think about the full
> >> >enumerate being right or wrong, I have this vague feeling that I'd li=
ke
> >> >to have this implemented fully at one point.  My cat disapproves, but=
 we
> >> >can't agree on everything, I guess.  Another configuration option in
> >> >/etc/nsswitch.conf might comfort her.
> >>=20
> >> I don't know if this has been mentioned but would a cache help here,
> >> i.e., nscd?  I think that's how Linux deals with this type of situatio=
n.
> >
> >Caching is wonderful for the usual requests for single entries from the
> >DB, and for this we have already two caches, the LSA cache and Cygwin's
> >own cache.  But caching doesn't help at all when enumerating.
> >
> >There's also the problem to rely on an external program.
>=20
> But that's no different than Linux.  I've never looked at the code but
> apparently libc has hooks for talking to nscd.  We could do the same
> with cygserver.
>=20
> >If it turns out that the current implementation is too slow, I'm
> >prepared to add caching to cygserver to have a system-wide caching
> >server, but Cygwin shouldn't *require* that cygserver runs.  And either
> >way, it still wouldn't help when enumerating all accounts.
>=20
> nscd does more than just keep information around in memory.  As I said,
> it's how Linux deals with this situation.  I know because I didn't install
> nscd when setting up a minimal Fedora 20 server at work and was met with
> awful lags and timeouts in services which tried to read from our nis.
> So Fedora doesn't require nscd but it sure does help.
>=20
> But, even after having set it up, I still have to remember not to do
> ls ~cg<tab> because it just takes forever.  So, if it is possible to
> enumerate users then I think you just do it and let people learn the
> cost.

Yes, I think so too.  I have some preliminary code (actually, just
empty function shells right now) which are supposed to implement
full enumerating.

However, system admins might not exactly approve.  I discussed this
with our Linux folks, and I learned that NSS backends like SSSD or
winbind default to NOT allowing enumerating, but giving the admin a
choice to enable it.

So I think for our case a configuration option in /etc/nsswitch.conf
to limit the scope of the enumeration might be feasible.


Corinna

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

--tctmm6wHVGT/P6vA
Content-Type: application/pgp-signature

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

iQIcBAEBAgAGBQJS/NpDAAoJEPU2Bp2uRE+g4VEP/jIE86/jrLRK1a/tv5xA4jW/
IndqfnsbUfgcwDnFFj7sQSnWhfx3ymFIJYSED2WaO86Z6vPu5QsG6k9Z+VCaxbYD
XX5uL2Zb4uuuz32b8jtAOL0kI+TqRzFz7HSPDF3cItkwf+2AobtBg+VPI0TAF787
7UX45dMVZHfI1zXdI/Gi0B4Ngplat/wyftZ8+/N2h/AwEisWSBleuj+bgyLDzi3C
Ve1J1+C08cqTzbRAgygrIeSrs3J/aW1KkUZVfu2OIUh2+6TJ9h+0v1ikTkoTVNZu
N6NHfZwX9SzT0RiaGXORqK39S4gv4u6eXiQ536sVCHgRWa3wLZr1yLjaBlfqmDpz
TduLn8bqIwLmCJB2wPo7XNDfQUJFd4KumDZkn7EHYZ8El1ZBb6sk+RzwKCjQPoTF
EnCt1eNSRffA7PulpYHEs9r8wcMo/ox3uOCeZvdRDAZk/lAlQDOx1CUReNpeJz+D
eKQmSrPxtByHb7aMyGCGhE4633/mO5n0OwdL5ZEZg/pSuHShJGeAzXHNAtg0h9gu
5YMdNP2ifwFEl70BXKYFwFBn9/e5GpNqq7A0vEz9f+kxkURSONACImZKZh5pVOv4
OdZDtFYqPCnGdPsqBiIb889SoBIStZNmnkG3dXml7HKwIBE1hNNhhTaKhRZxpoLT
6J8eECz2tE7rRP80JTW6
=GG1s
-----END PGP SIGNATURE-----

--tctmm6wHVGT/P6vA--