Mail Archives: cygwin/2014/07/28/05:22:14
--f2QGlHpHGjS2mn6Y
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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 proce=
ss
> > > in a process tree fetches all POSIX offsets of all trusted domains ri=
ght
> > > 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:
> > >=20
> > > - 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 < 0x1100=
00
> > > or offsets > 0xff000000. If the first process in the tree=20
> > >=20
> > > - The UID/GID values would be stable throughout the process tree.
> > >=20
> > > - The UID/GID values would be stable systemwide when utilizing cygser=
ver.
> > >=20
> > > 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=E2=80=99m still not convinced that we have =
to
> > workaround. After all, since i don=E2=80=99t care the other domains in =
my daily
> > work, i=E2=80=99m 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.
> >=20
> > But we can consider the other way and for that i will use a comparison:
> > using special characters (like =E2=80=98\n=E2=80=99) gratuitously in th=
e middle of filenames
> > is usually considered as a bad practice, but always possible by
> > doing =E2=80=98char *filename =3D "a\nb"; fopen(filename, "w")=E2=80=99=
. Now, once this
> > file is created, you can use =E2=80=98ls=E2=80=99 in the folder. Do you=
think =E2=80=98ls'
> > should respect user decision and display the raw \n in its output or
> > try to workaround by using some substitution character (like =E2=80=98?=
=E2=80=99) in order
> > not to wrap at unexpected locations? The answer is that =E2=80=98ls=E2=
=80=99 substitutes
> > by default, but also provides a full group of related options to change=
this
> > behavior (--quoting-style=3DWORD, --hide-control-chars).
> >=20
> > Of course, adding options (eg in nsswitch.conf) to orientate the assign=
ment
> > of posixOffsets to various substitutes would be useless. Even assigning
> > the null posixOffsets to non-null values, i=E2=80=99m not convinced of.
>=20
> We really should do that to avoid collisions with system accounts, IMHO.
>=20
> 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:
>=20
> Case 1: posix offset is < 0x100000 =3D=3D> 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)
> =3D=3D> Enforce posix offset 0xfe000000.
>=20
> 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
--=20
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
--f2QGlHpHGjS2mn6Y
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBAgAGBQJT1hYsAAoJEPU2Bp2uRE+gueMP/0ujaTSZfuth3nAIplZt3q8/
SkfJXXiIJnrBfFcV1zu9CrIOcDXa4l81qqvTjhp+/nt0aeoRvcdn5O0eJO/Kqd9l
ZcGwN5NVTWUz8Peq1WpK5dZpdh9mWF28y7oxYmtgoopZx5XBDz2DuFL+jXeAbh2r
daONgW3jPisw+febTGH/AHP+tychmvLy8I6auvAvkCBzVGcW4XsFazA3FO91MfTN
FxI9av1AqjJyXiArE2SZIfRgwAN3jyr1yROYXcFadoHPfxpFkXzFsQoGfvGUrvP2
hhPfiRz/EE8i/n/qYD1yS482AXlMUi/YgKZaU9r2GJ9/9TZkrY232FCI+J2g5gvm
XxvG/nwnTaYfdI44IkNm6Wu6ekV4lJc69/7Y5hBz2IRoSGf858jnYJwFLJKPcZmS
r9drE10SvIwHoVGDx8ZGtAdEHMMR2DgQZOd1vt06V4W7kqqM4GeCKUJD6l59Bki3
+bzo4Zhv7MMVQsLGK32o5JoSp3CRcCUadY+pFaoPuncMq6KNI3H3seYwCaa9fKrX
Lyjk6r0z2W86y9+8hBokiJNpsIt7Jv5t2CHXjNFWhE+uXPf4c8vfsLYKyzs55fwN
L0uT/7aDdQlUPCirxukJhJYpKrcoHfwAkk0En+t/+OWbvjgjeNTjctyCpWSh65MY
TVk0gbrUZWjyVh/MBjx7
=H7X4
-----END PGP SIGNATURE-----
--f2QGlHpHGjS2mn6Y--
- Raw text -