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:
> >>>>> 
> >>>>> I have encountered this case in real life. The domain admins have set
> >>>>> the trustPosixOffset of the secondary domain to zero. This value is therefore
> >>>>> never recorded and the cldap->open occurs again and again.
> >>>> 
> >>>> Ouch.  Why on earth are admins doing this?  There's no way to
> >>>> workaround this reliably.
> >>>> 
> >>> Reliably i don’t know. I’ve modified uinfo.cc in order that the special value
> >>> for td->PosixOffset is no longer 0. Taking into account that LDAP_SERVER_DOWN
> >>> is now recognized, my ‘getent passwd’ executes gracefully in 40 minutes
> >>> (instead of 60) and ‘getent group’ in 25 minutes (instead of 90). Also quicker
> >>> is ‘mkpasswd -d secondary_domain’ of course. Patch attached.
> >> 
> >> 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.
> >> 
> >> A POSIX offset of 0 is bad.  If other trusted domains have no functional
> >> 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.
> >> 
> >> 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.
> >> 
> >> There are two ways to workaround that.
> >> 
> >> - The better solution is to inform your IT of the problem.
> >> 
> >> - The not so well one is to enhance /etc/nsswitch.conf to allow to
> >>  define POSIX offsets for domains indepedent of the AD setting.
> > 
> > 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=0). When you enumerate,
> you get a PosixOffset that takes into account the previously encountered
> secondary domains with PosixOffset=0, say you get UNIX_POSIX_OFFSET-3*0x00800000

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’m still not sure we have to workaround IT "madness" at all. First, IT
> people might set PosixOffset to 1 for each domain and you cannot catch this kind
> of alternate madness. Also, be sure that if some user someday suffers from 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 

- 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

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