Re: Simplify AD integration?

[Corinna Vinschen <corinna-cygwin@cygwin.com>]

[-- Attachment #1: Type: text/plain, Size: 5565 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]