This is the mail archive of the cygwin mailing list for the Cygwin project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Ping? On Jul 18 21:18, Corinna Vinschen wrote: > On Jul 17 08:33, Denis Excoffier wrote: > > On 2014-07-16 15:51, Corinna Vinschen wrote: > > > 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. > > I buy this of course, but iâm still not convinced that we have to > > workaround. After all, since i donât care the other domains in my daily > > work, iâm not affected at all. Most of the users will never be affected > > i suppose. And if Cygwin happens to circumvent a null posixOffset by > > providing its own, there will be even less chances for collisions and > > for collisions being reported. > > > > But we can consider the other way and for that i will use a comparison: > > using special characters (like â\nâ) gratuitously in the middle of filenames > > is usually considered as a bad practice, but always possible by > > doing âchar *filename = "a\nb"; fopen(filename, "w")â. Now, once this > > file is created, you can use âlsâ in the folder. Do you think âls' > > should respect user decision and display the raw \n in its output or > > try to workaround by using some substitution character (like â?â) in order > > not to wrap at unexpected locations? The answer is that âlsâ substitutes > > by default, but also provides a full group of related options to change this > > behavior (--quoting-style=WORD, --hide-control-chars). > > > > Of course, adding options (eg in nsswitch.conf) to orientate the assignment > > of posixOffsets to various substitutes would be useless. Even assigning > > the null posixOffsets to non-null values, iâm not convinced of. > > We really should do that to avoid collisions with system accounts, IMHO. > > But maybe we should handle it as a border case of a border case, and > reliably. Rather than using the default fake mechanism, what if > we use default offsets for the two cases: > > Case 1: posix offset is < 0x100000 ==> Enforce posix 0ffset 0xfe80000 > Case 2: posix offset can't be fetched (this points to a local user > having no access to this kind of domain information) > ==> Enforce posix offset 0xfe000000. > > This would result in potential collisions in very rare border cases, > but it would result in reliable mappings throught all processes. > And, the complexity would be quite small. any feedback on this one? Shall I create a snapshot with a matching patch? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Attachment:
pgpDX9k0QhS6R.pgp
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |