Mail Archives: cygwin/2014/07/16/09:52:16
--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--
- Raw text -