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=Gy5Ljis1Qj1Hpl1iBEu1E0W6MwA027UiQe2TcPOkiIGPrJ21i08rN
	SO1YPlEQgVrOuIOn9NNbBkpMnTE8Wr091PDd7hjhrSCN5jYSA4C+dmdE76RTVAZG
	tRj5xNZ1ArE2k/4Revg0RiGdIxBTr/bf5MidFEZTUTyZ9M2tuYJs5A=
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=qbWWtEvrqR3E+ks/mSXzl2jYKNA=; b=jkraa/k/9Lr4+WYnpzgUrQWK1Ws9
	EOUONGamCuEZ6EEIHA1EkUpNTxHqslYQUPncS6SIlMEN++mmf2eT8gP/VJIsuNov
	3zuogACxpG0E7IFupFp1umh7dDIVl3SnkClREaXIvT5kYzHdqylH0n6u4w6uxpyW
	TtSRV4oJ5vHEGI0=
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=-4.4 required=5.0 tests=AWL,BAYES_00,LIKELY_SPAM_BODY,THIS_AD autolearn=no version=3.3.2
X-HELO: calimero.vinschen.de
Date: Wed, 16 Jul 2014 15:51:51 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: timeout in LDAP access
Message-ID: <20140716135151.GC8520@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <E760D646-FFCB-434C-B990-7783DC011326 AT Denis-Excoffier DOT org> <20140625211355 DOT GA25116 AT calimero DOT vinschen DOT de> <E3509AAC-C4A0-4293-988F-E94BF2421180 AT free DOT fr> <20140707110714 DOT GJ1803 AT calimero DOT vinschen DOT de> <19B9F8D8-7FD6-4A7B-AC83-BBF8D152319D AT Denis-Excoffier DOT org> <20140709101256 DOT GD26447 AT calimero DOT vinschen DOT de> <BA09D7D8-96E6-431F-9434-8BA8A2AB4952 AT Denis-Excoffier DOT org> <20140714095107 DOT GB10401 AT calimero DOT vinschen DOT de> <20140714134836 DOT GA2637 AT calimero DOT vinschen DOT de> <79A8CE40-E412-4479-B058-378823313FA8 AT Denis-Excoffier DOT org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;	protocol="application/pgp-signature"; boundary="XMCwj5IQnwKtuyBG"
Content-Disposition: inline
In-Reply-To: <79A8CE40-E412-4479-B058-378823313FA8@Denis-Excoffier.org>
User-Agent: Mutt/1.5.23 (2014-03-12)

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

On Jul 15 18:29, Denis Excoffier wrote:
> On 2014-07-14 15:48 Corinna Vinschen wrote:
> > On Jul 14 11:51, Corinna Vinschen wrote:
> >> On Jul 12 15:39, Denis Excoffier wrote:
> >>> On 2014-07-09 12:12 Corinna Vinschen wrote:
> >>>>>=20
> >>>>> I have encountered this case in real life. The domain admins have s=
et
> >>>>> the trustPosixOffset of the secondary domain to zero. This value is=
 therefore
> >>>>> never recorded and the cldap->open occurs again and again.
> >>>>=20
> >>>> Ouch.  Why on earth are admins doing this?  There's no way to
> >>>> workaround this reliably.
> >>>>=20
> >>> Reliably i don=E2=80=99t know. I=E2=80=99ve modified uinfo.cc in orde=
r that the special value
> >>> for td->PosixOffset is no longer 0. Taking into account that LDAP_SER=
VER_DOWN
> >>> is now recognized, my =E2=80=98getent passwd=E2=80=99 executes gracef=
ully in 40 minutes
> >>> (instead of 60) and =E2=80=98getent group=E2=80=99 in 25 minutes (ins=
tead of 90). Also quicker
> >>> is =E2=80=98mkpasswd -d secondary_domain=E2=80=99 of course. Patch at=
tached.
> >>=20
> >> That won't work.  It works around your immediate problem by defining
> >> a non-0 start value, no doubt about that, but it doesn't fix the
> >> underlying problem.
> >>=20
> >> A POSIX offset of 0 is bad.  If other trusted domains have no function=
al
> >> POSIX offset value, but are set to 0 instead, they won't have different
> >> UID values for accounts of different domains.  Two users from different
> >> domains, both with RID 1000 will both have UID 1000 in Cygwin.  Also,
> >> the lower UID numbers are reserved for special accounts.
> >>=20
> >> There is no guarantee that there won't be a collision at some point of
> >> the 32 bit UID spectrum, but a POSIX offset of 0 will almost guarantee
> >> the collision.
> >>=20
> >> There are two ways to workaround that.
> >>=20
> >> - The better solution is to inform your IT of the problem.
> >>=20
> >> - The not so well one is to enhance /etc/nsswitch.conf to allow to
> >>  define POSIX offsets for domains indepedent of the AD setting.
> >=20
> > I tried the third solution for the time being, which is, generating the
> > fake POSIX offset a bit differently.  Fake offsets are a bit dangerous
> > in that there's no guarantee that you get a stable mapping between SID
> > and UID/GID, but it's *hopefully* a border situation we're trying to
> > workaround.  Please give the latest developer snashot from
> > http://cygwin.com/snapshots/ a try.
> Tried and it works as expected. However there is a design bug. Suppose you
> have a SID from a non-primary domain (with PosixOffset=3D0). When you enu=
merate,
> you get a PosixOffset that takes into account the previously encountered
> secondary domains with PosixOffset=3D0, say you get UNIX_POSIX_OFFSET-3*0=
x00800000

That was, actually, not a design bug but a deliberate decision.  In some
way we have to work with accounts from a badly defined domain, but for
those getent isn't the problem.  You don't need to enumerate all domains
except in very rare cases.

What should work, though, is to ls -l files and see the correct owner of
a file and to chmod the files.  For everything else I would opt for
kicking your IT.  Keep in mind that AD chooses more or less sane POSIX
offsets for trusted domains by default.  Setting it to 0 is an entirely
gratuitious act by the admin.  A service desk ticket might be helpful.

> Independently, i=E2=80=99m still not sure we have to workaround IT "madne=
ss" at all. First, IT
> people might set PosixOffset to 1 for each domain and you cannot catch th=
is kind
> of alternate madness. Also, be sure that if some user someday suffers fro=
m a duplicate

Yes, you can.  IT has to know there's software running which needs
sane POSIX offset settings.

Alternatively we can still implement some other workaround at one point.

It occured to me that there's another way to do that.  The problem
you're mentioning above could be alleviated if the first Cygwin process
in a process tree fetches all POSIX offsets of all trusted domains right
at the start, rather than fetching the POSIX offsets only on demand by
whatever process needs it.  This would slow down the startup of the
first process slightly (one LDAP request per trusted domain, but only
asking your primary DC), but this would have two advantages:

- After fetching all POSIX offsets, we could filter out all POSIX
  offsets which don't make sense.  These would be set using the fake
  offset setting mechanism.  "No sense" would include offsets < 0x110000
  or offsets > 0xff000000.  If the first process in the tree=20

- The UID/GID values would be stable throughout the process tree.

- The UID/GID values would be stable systemwide when utilizing cygserver.

That's a bit of work, but Cygwin 1.7.31 will still come without this
AD integration code anyway, so we still have time to turn everything
upside down.


Corinna

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

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

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

iQIcBAEBAgAGBQJTxoN3AAoJEPU2Bp2uRE+gpQwP/0ty5Hh6ZsEIugSq4MxYqK90
6szihV19Bz0gxUjbSkJpMIkuRUTBeU7v4kAPMwxJMPdAEKv5bzqXFnq5eJZJH8bE
UM3Qb4kHV/x5TcdXu7WrNYC/7+0lmACzEnO9HfssrCKAvisfutoOnlsZUpATNc8P
U3IdOPmD/ht0Fb2VumXWGRR5cdk5wRo0/sQ1MppGBIF5mUta/pLX7uwPMhFBk3lI
f6jvuFhpzXRPe+fxpzI0SN4nlqDntbZYgs4IzzxVWHIHGk+F7uBIbE1+KlOkNYnZ
GcFvSL2l2j972jrkyWHCypwANwW3+ddv3FRstweQLZYeSWcXhOXualfVWSmarnbL
i9fMo2p3Leqe/Vxp3zVtHhF9sEcJakLxdt+8Das7ibFVw7uQcfagcUHQ9Seizzpi
rlljt98lvRFl267M9G4e1jB6xY49Lu02+GHQG/rPfVO8OXUVppbAfsG8iiUs+mYM
mrSpGyBXWdwTJAGt6e9ZFOsAJciBQifa9Vvl8GZUgO4PDfyInRF/AOR9DiRkakt0
6uBjjObAqDQJzarWn8Lqwpq/UvDM253/zlJ9GqTkbb1o4tA7ss/wVRjNm8p8zvdz
K9nFk9oaApmhuqYet4gR6qirDqLeH9TpyCoGsboynUgOTMPb+buHGAFDmSk7adaa
XkEO3puFrXJ3tICSjXzJ
=Yisv
-----END PGP SIGNATURE-----

--XMCwj5IQnwKtuyBG--