Mail Archives: cygwin/2014/07/30/14:10:47
--qceGWDlIblb6GsvIfjFAflE6xqV0WuxDa
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
[resend; apologies for the encryption snafu]
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
> 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.
I'm really worried about the leading + thing.
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"]
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 '+'.
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].
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 favored:
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)
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.
>=20
> 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?
I'm in favor of removing leading +
>=20
> 2. Shall we stick to '+' as the separator char or choose another one?
> If so, which one?
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
> 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?
No opinion.
>=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'?
I kind of like case preservation, but if windows usernames are
case-insensitive, I could also live with always downcasing names.
--=20
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
--qceGWDlIblb6GsvIfjFAflE6xqV0WuxDa
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Public key at http://people.redhat.com/eblake/eblake.gpg
iQEcBAEBCAAGBQJT2TUQAAoJEKeha0olJ0NqNukH/jmlpHrzMafICReD/yvCJ/lw
iC8znPFg8Er9EhYF7mEcnENYZ+hJpCAXwzFzJr6rJhWDd6Kr3aPI0UpJJkR1KFWS
iUgUwFS5IkZG5W069KFsgcEIiPnyU6hVzgVld8gbEqKWqRcyF/jutADliXikOLW1
J3g+FgkMgoLgDUk+/Py5hK4F0BX/hPTlmwWKJInXuPzxdRH/PLk54Rs4Wt396ovg
gEffmzxf57Lu81zVO7bwQf0d5szxJ17JwkNx+qbgwimI5JeWUiv7Eclma3o9Ti+8
4dYTEI1+7J4luFEpTyfX18504LRM+l0Lze3Z5zHqDLbzptbupSW7d7aSMbGNZ9U=
=xYeX
-----END PGP SIGNATURE-----
--qceGWDlIblb6GsvIfjFAflE6xqV0WuxDa--
- Raw text -