From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21200 invoked by alias); 30 Jul 2014 18:43:54 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 21188 invoked by uid 89); 30 Jul 2014 18:43:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-5.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: calimero.vinschen.de Received: from aquarius.hirmke.de (HELO calimero.vinschen.de) (217.91.18.234) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 30 Jul 2014 18:43:52 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id ED5A48E05FF; Wed, 30 Jul 2014 20:43:49 +0200 (CEST) Date: Wed, 30 Jul 2014 18:43:00 -0000 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: Simplify AD integration? Message-ID: <20140730184349.GT25860@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <20140730134716.GM25860@calimero.vinschen.de> <53D93510.6020903@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7pXD3OQNRL3RjWCz" Content-Disposition: inline In-Reply-To: <53D93510.6020903@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2014-07/txt/msg00357.txt.bz2 --7pXD3OQNRL3RjWCz Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 5499 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 Content-length: 819 -----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--