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
But you can also jump directly to the non-primary domain of this SID, eg by ‘getent passwd SID’. In this case you get UNIX_POSIX_OFFSET-0x00800000. In fact, real code is a little bit more complex, but you get the point: ‘getent passwd’ and ‘getent passwd SID’ will not give the same UID for a given SID, the AD remaining unmodified. 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 UID situation, this will be reported to them and hopefully addressed (or not because this might be expected), but most probably for a single domain. We have to live with PosixOffset=0. Yet, under the assumption that PosixOffsets are not modified by Cygwin, previous uinfo.cc (snapshot dated 20140709) is not so efficient when PosixOffset=0 (eg too many connect’s), and i think my patch makes a better Cygwin than with no patch. Probably it can also be improved to remove the special value. Regards, Denis Excoffier. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
