Mail Archives: cygwin/2014/07/30/14:44:09
--7pXD3OQNRL3RjWCz
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Jul 30 12:10, Eric Blake wrote:
> [resend; apologies for the encryption snafu]
>=20
> On 07/30/2014 07:47 AM, Corinna Vinschen wrote:
> >=20
> > Default is 'auto':
> >=20
> > builtin accounts; "+SYSTEM", "+LOCAL", etc.
> > primary domain "corinna", "cgf", ...
> > other domain: "DOMAIN1+walter", "DOMAIN2+mathilda"
> >=20
>=20
> >=20
> > Also, the leading '+' for builtin accounts results in some downsides,
> > one of them for instance the fact that `chown +x' assumes that x is a
> > numerical uid or gid. Thus `chown +SYSTEM ...' fails. On the other
> > hand it simplifies the account handling inside of Cygwin.
>=20
> I'm really worried about the leading + thing.
>=20
> Back-story: On Linux (and I presume Windows, although I haven't tested),
> it is possible to create an all-numeric username. Worse, it is possible
> for this name to NOT match its underlying uid. [In all seriousness, I
> have a user named "0" on my Linux system with uid 1002, just to prove
> this and test corner cases of applications that do both uid and name
> lookups, to see if I can get the code to misbehave by giving me uid-0
> privileges instead of uid-1002 privileges when I pass in the string "0"]
>=20
> So in coreutils and several other applications, there is a workaround:
> code that passes in an arbitrary user string tries both name and uid
> lookup, but code that passes in a leading + tries only a uid lookup
> (since +0 is numeric, but POSIX forbids '+' in portable user names, the
> leading '+' is sufficient to let this hack work upstream). That is,
> 'chown 0 file' will _usually_ give uid 0 to the file, but may be tricked
> into giving the file uid 1002; but 'chown +0 file' will always give uid
> 0 to the file, since +0 will never be a user name on Linux. In
> coreutils, at least 'chown', 'id', and 'chroot' all have this same
> semantics of leading '+'.
>=20
> If cygwin adopts +SYSTEM in order to special-case builtin accounts, I
> think we are fairly safe that there are no builtin accounts with
> all-numeric names. BUT, I would have to patch the cygwin build of
> coreutils to special-case the special-case - where the code now only
> looks for leading + as the designation for doing numeric-only lookup, on
> cygwin, it would have to look for +[all-digits] vs. +[alphanumeric].
>=20
> Meanwhile, what's the penalty if you _don't_ use a leading +? That is,
> I get that if there is both a local user named "foo" and a user named
> "DOMAIN\foo", you want "foo" to favor the domain use, not the local use.
> But Windows won't let you have "DOMAIN\SYSTEM" (I don't know if that's
> true for all builtins, or just a subset). It seems to me that you are
> debating between two possibilities to ensure that domain names are favore=
d:
>=20
> 1. calling LookupAccountName("foo") possibly followed by
> LookupAccountName("MYDOMAIN\foo") (single lookup for builtins, and even
> for local users where the user happens to already belong to the right
> domain; double lookup where the call fails but a domain user might
> exist, or where the call succeeds but in a different domain than
> expected so retrying in the preferred domain might make a difference)
> 2. calling LookupAccountName("MYDOMAIN/SYSTEM") possibly followed by
> LookupAccountName("SYSTEM") (single lookup for successful domain names,
> double lookup for builtins)
>=20
> As I understand it, using the leading + would be a micro-optimization to
> allow you to avoid a second call in more cases. But how much penalty is
> it to do two calls, and can we figure out whether style 1 or style 2 is
> likely to have fewer cases that need the second call to begin with?
> That is, avoiding a leading '+' would be friendlier to coreutils and
> other software, even if it is slightly more expensive for cygwin to
> sometimes have to do double lookups for answers that weren't definitive
> on the first try.
Good points. I might have overvalued the gain of easily recognizing
builtin accounts by the leading '+' separator.
Big, big, hmmmmm, *thinking*...
> > So I'd like to ask a few questions to which I'd like to have some brief
> > answers, kind of like a poll, to get a better idea how we should
> > proceed:
> >=20
> > 1. Shall we remove the leading '+' from the builtin account names
> > or shall we keep it?
>=20
> I'm in favor of removing leading +
>=20
> >=20
> > 2. Shall we stick to '+' as the separator char or choose another one?
> > If so, which one?
>=20
> Keeping + as mid-name separator is still best in my mind (Certainly
> better than ':', '\\', or '/', and there aren't many other characters
> besides ',' or '%' that would survive use through shell tilde-expansion
> while still being unlikely in the middle of a user name). Mid-string is
> different than leading +.
>=20
> >=20
> > 3. Shall we keep the `db_prefix' variability or choose one of
> > the prefixing methods and stick to it? If so, which one, auto,
> > primary, or always?
>=20
> No opinion.
>=20
> >=20
> > Bonus question:
> >=20
> > 4. Should Cygwin downcase all usernames when generating the Cygwin
> > username, so, if your Windows username is 'Ralph', your Cygwin
> > username will be 'ralph'?
>=20
> I kind of like case preservation, but if windows usernames are
> case-insensitive, I could also live with always downcasing names.
Corinna
--=20
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
--7pXD3OQNRL3RjWCz
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBAgAGBQJT2TzlAAoJEPU2Bp2uRE+gyisP/i6MIQIhDFStdXkYxYZngf1O
dPhLlU42tyUu14usJ63WIHDrpK8MKBpHko2Mo7y9dRtayXGri8z6A7FzDuLww8od
V7oE9DW6Ymy6F0qBbW/+2TznOm7SjlINcBK7XzWZHg9/nPHWErtIguHt3BePxVR4
7/JkaH7R5abUbgdK8SULvVnL8drhvjC8OpJTVvjO9xpB1LWsUjqGcQI5Gp1oL+Q5
alBjmZ7yr77uSaVwSqE2vF8CgEyX8yhRn9/nNh/YZhwAyljvhNYuU8GkeOi3GZ1d
enCx0qsAOlqaw6Kh5WFKnHyseWfGe1XogkolnobmgSZQMytNzOYI3MLHdYPG8mTL
k11lY8R3Y5h1MkABbn3QZMShJp/3eVsqMKVfm88DCiFyqH1s9VUqcu4XaceG690s
E5NhGNOem57CA/VqvqpkfRHsouiezfP6YfSzQai5i7fB2cOOiTICa+4C7866xVfW
s9k0M55DwPyBWmSL4iwvY61abhQJE4twzFqlzOifvURa2GZLtDuUCofiHv3r/ML7
+hdUPvYRQOHKaVlIynBRgYECcTuqq9Q82T66ebUJLc8N72JLYyKXUS9Vk2KKELZQ
n96bsyMazocGZ1j0FcZAPjtKb3apFmKF4hCQKrJADs2IrPR8w0HGvLORElfvEjyw
9Rsrcd3rCb0YTkuqZPdN
=LZYo
-----END PGP SIGNATURE-----
--7pXD3OQNRL3RjWCz--
- Raw text -