On Jul 30 12:10, Eric Blake wrote:
> [resend; apologies for the encryption snafu]
>
> On 07/30/2014 07:47 AM, Corinna Vinschen wrote:
> >
> > Default is 'auto':
> >
> > builtin accounts; "+SYSTEM", "+LOCAL", etc.
> > primary domain "corinna", "cgf", ...
> > other domain: "DOMAIN1+walter", "DOMAIN2+mathilda"
> >
>
> >
> > 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.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: > > > > 1. Shall we remove the leading '+' from the builtin account names > > or shall we keep it? > > I'm in favor of removing leading + > > > > > 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 +. > > > > > 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. > > > > > Bonus question: > > > > 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. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
pgp8pNJj0d2FX.pgp
Description: PGP signature
