Re: Simplify AD integration?
On Aug 6 10:47, Corinna Vinschen wrote: On Aug 4 21:00, Corinna Vinschen wrote: I just uploaded a new snapshot to http://cygwin.com/snapshots/ This snapshot contains only a single change: It drops the prepended plus entirely, So the builtin and well-known accounts are now called as familiar: SYSTEM instead of +SYSTEM, Administrators instead of +Administrators, etc. The documentation doesn't reflect this change yet, but I will fix that pretty soon. As for other changes, I'm still not sure since we seem to have as many different opinions as interested community members :} I would still like to drop the db_prefix and db_separator settings and just stick to the setting called auto: builtin accounts; SYSTEM, Administrators, etc. primary domain corinna, yaakov, ... This is typically all you see on non-domain machines. On domain maches, add this: other domain: DOMAIN1+walter, DOMAIN2+mathilda (local SAM accounts are subsumed under other domain here). Would anybody have really terrible problems with this approach? If so, what problems? So nobody would really have a problem? Wow, that's cool. I guess I'll remove the db_prefix and db_separator settings pretty soon. Done. For the time being I decided to keep the code intact, but to disable the ability to change the settings from /etc/nsswitch.conf. This leaves us with a very simple nsswitch.conf which only understands passwd: group: db_enum: This is in the latest snapshot from https://cygwin.com/snapshots/ Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpdgc3xqRy4O.pgp Description: PGP signature
Re: Simplify AD integration?
On Aug 4 21:00, Corinna Vinschen wrote: I just uploaded a new snapshot to http://cygwin.com/snapshots/ This snapshot contains only a single change: It drops the prepended plus entirely, So the builtin and well-known accounts are now called as familiar: SYSTEM instead of +SYSTEM, Administrators instead of +Administrators, etc. The documentation doesn't reflect this change yet, but I will fix that pretty soon. As for other changes, I'm still not sure since we seem to have as many different opinions as interested community members :} I would still like to drop the db_prefix and db_separator settings and just stick to the setting called auto: builtin accounts; SYSTEM, Administrators, etc. primary domain corinna, yaakov, ... This is typically all you see on non-domain machines. On domain maches, add this: other domain: DOMAIN1+walter, DOMAIN2+mathilda (local SAM accounts are subsumed under other domain here). Would anybody have really terrible problems with this approach? If so, what problems? So nobody would really have a problem? Wow, that's cool. I guess I'll remove the db_prefix and db_separator settings pretty soon. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpvVkAaOyhRB.pgp Description: PGP signature
Re: Simplify AD integration?
On Jul 30 20:43, Corinna Vinschen wrote: 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. [...] Good points. I might have overvalued the gain of easily recognizing builtin accounts by the leading '+' separator. Big, big, hm, *thinking*... I just uploaded a new snapshot to http://cygwin.com/snapshots/ This snapshot contains only a single change: It drops the prepended plus entirely, So the builtin and well-known accounts are now called as familiar: SYSTEM instead of +SYSTEM, Administrators instead of +Administrators, etc. The documentation doesn't reflect this change yet, but I will fix that pretty soon. As for other changes, I'm still not sure since we seem to have as many different opinions as interested community members :} I would still like to drop the db_prefix and db_separator settings and just stick to the setting called auto: builtin accounts; SYSTEM, Administrators, etc. primary domain corinna, yaakov, ... This is typically all you see on non-domain machines. On domain maches, add this: other domain: DOMAIN1+walter, DOMAIN2+mathilda (local SAM accounts are subsumed under other domain here). Would anybody have really terrible problems with this approach? If so, what problems? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgptWVHwa5iOM.pgp Description: PGP signature
Re: Simplify AD integration?
On Jul 31 07:12, Achim Gratz wrote: Corinna Vinschen corinna-cygwin at cygwin.com writes: Good points. I might have overvalued the gain of easily recognizing builtin accounts by the leading '+' separator. After some thinking with my eyes closed... not prefixing local accounts at all would at least allow the sshd to see the local sshd user without jumping through hoops, so that might be a net gain after all. What I don't know: what happens if a local and a primary domain user have the same name? You misinterpreted what I described. Please re-read my preliminary documentation. The prefixing is used for *builtin* and *well-known* accounts, *not* for local accounts. Local accounts from the local SAM, users and groups, are either - not prefixed at all, if the machine is a standalone machine, or - prefixed with the machine name if the machine is member of a domain. The non-prefixed, name-only account names are exclusively used for the *primary* domain of the machine you're working on, *iff* db_prefix is set to auto. This is either the domain the machine has been added to, or the machine name itself if it's a standalone machine. I hope that clears things up. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpvwQNkcCLAs.pgp Description: PGP signature
Re: Simplify AD integration?
On Jul 30 18:23, Larry Hall (Cygwin) wrote: On 07/30/2014 05:19 PM, Andrew DeFaria wrote: snip Ah yes. That makes sense I guess. But does this mean that things will come in with the base package like /etc/nsswitch.conf, etc? Right now, the documentation hints that it's up to the user to create this file. Whether there will be a configure script at some point to help create a first version, that's something for Corinna to comment on. I'm not sure yet. I guess I'll be going for a short /etc/nsswitch.conf file containing just the default values as comments and a pointer to the documentation. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpRgKR3OCCmn.pgp Description: PGP signature
Re: Simplify AD integration?
On Jul 31 17:39, D. Boland wrote: Eric Blake wrote: On 07/31/2014 07:26 AM, D. Boland wrote: Corinna Vinschen wrote: 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? 2. Shall we stick to '+' as the separator char or choose another one? If so, which one? 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? I'm a legacy man. So I would say keep the MS symbol and use it like this \daniel, \SYSTEM, etc. But you'd have to write that as '\daniel' or \\daniel in the shell, and you also cripple tilde expansion. That's why we already ruled out :, \, and / as non-starters, as mentioned elsewhere in this thread. I am not only a man of legacy, but also a very opinionated one. So give me some slack when I say: the whole thing is insane. This would mean that from now on, I have to use constructs like ~+daniel ~+SYSTEM in a Linux shell?? Bizarre. No, of course not. Please have a look into my preliminary documentation. and try the latest snapshot. Add an /etc/nsswitch.conf file with the following content: --- passwd: db group: db --- Then restart your Cygwin shell window. Call `id'. It will give you a first clue. Then have a look into the documentation and play with the nsswitch.conf settings described in the last section. On the other hand, for the sake of progress, but keeping legacy there would be only one acceptable solution: use the tilde symbol. A user could then be referred to as: ~daniel. Since domain-less prefixing is only done for builtin accounts, it won't affect your user account anyway. But still, the tilde would be bad. If you want to cd to your home dir using the tilde expression, you'd have to use it twice: $ cd ~~daniel But, again, this won't happen anyway. Your username is either daniel, or DOMAIN~daniel (assuming you use tilde as separator). Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpKKcBtMqp5e.pgp Description: PGP signature
Re: Simplify AD integration?
On Jul 31 23:06, Christoph H. Hochstaetter wrote: Corinna Vinschen wrote: Default is 'auto': builtin accounts; +SYSTEM, +LOCAL, etc. primary domain corinna, cgf, ... other domain: DOMAIN1+walter, DOMAIN2+mathilda If set to 'primary': builtin accounts; +SYSTEM, +LOCAL, etc. primary domain MYDOMAIN+corinna, MYDOMAIN+cgf, ... other domain: DOMAIN1+walter, DOMAIN2+mathilda If set to 'always': builtin accounts; NT AUTHORITY+SYSTEM, BULTIN+LOCAL, etc. primary domain MYDOMAIN+corinna, MYDOMAIN+cgf, ... other domain: DOMAIN1+walter, DOMAIN2+mathilda 1. Shall we remove the leading '+' from the builtin account names or shall we keep it? None of these three seem correct to me. It should be: builtin accounts; NT AUTHORITY+SYSTEM, BULTIN+LOCAL, etc. primary domain corinna, cgf, ... other domain: DOMAIN1+walter, DOMAIN2+mathilda The prefix-only variation for builtin and well-known acocunts is what's originally used by SFU. I cloned that behaviour as it seemed to have advantages handling getpwname/getgrnam calls. Windows treats NT AUTHORITY and BUILTIN as foreign domains like DOMAIN1 and DOMAIN2 in Win32 APIs that use a single string for domain and username, e.g. lpServiceStartName in CreateService. Examples: .\user1 - can be uses as a shortcut for MYDOMAIN\user1 [...] The Windows .\ prefixing is not at all utilized inside Cygwin. It has nothing to do with how the prefixing is evaluated. This should be at least configurable thru db_prefix even though most users might not want to see names like NT AUTHORITY+SYSTEM in ls -l. That's what you get with db_prefix auto or primary. 2. Shall we stick to '+' as the separator char or choose another one? If so, which one? Yes + is well known for that purpose in Linux and other Unixes. Keep db_separator in /etc/nsswitch.conf if possible 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? See above Bonus question: 4. Should Cygwin downcase all usernames when generating the Cygwin username I prefer downcase. Other users probably will not. So db_username_downcase = true/false would be great. Sigh. YA setting. I was trying to *simplify* the stuff and reduce variability since that stuff only complicates the code for... what gain? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpVM2J9lKXBU.pgp Description: PGP signature
Re: Simplify AD integration?
Andrey Repin wrote: Greetings, D. Boland! I am not only a man of legacy, but also a very opinionated one. So give me some slack when I say: the whole thing is insane. This would mean that from now on, I have to use constructs like ~+daniel ~+SYSTEM in a Linux shell?? Bizarre. No, you don't have. Default domain users are unprefixed, and the chance you would use internal accounts for something like shell access is exactly zero. For the god's sake, read the thread before posting into it. Everything has been discussed no more than two days ago. Yes, yes, I know. I wanted to react from the heart, without the intellectual baggage of knowing the technical intricacies behind the problem. D. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Simplify AD integration?
On 08/01/2014 06:01 AM, Corinna Vinschen wrote: Bonus question: 4. Should Cygwin downcase all usernames when generating the Cygwin username I prefer downcase. Other users probably will not. So db_username_downcase = true/false would be great. Sigh. YA setting. I was trying to*simplify* the stuff and reduce variability since that stuff only complicates the code for... what gain? Yes, that was my thinking as well. Automatic downcasing may be a convenient feature for some but it doesn't seem like a must have. It's always possible to address this with a change in the Windows user name casing or by adding the accounts that one wants to override to the passwd/ group files. I know each of these options has their downsides too but these seem like sufficient work-arounds for a potential need that isn't key functionality, IMHO. -- Larry _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Simplify AD integration?
On 8/1/2014 5:28 AM, D. Boland wrote: Andrey Repin wrote: Greetings, D. Boland! I am not only a man of legacy, but also a very opinionated one. So give me some slack when I say: the whole thing is insane. This would mean that from now on, I have to use constructs like ~+daniel ~+SYSTEM in a Linux shell?? Bizarre. No, you don't have. Default domain users are unprefixed, and the chance you would use internal accounts for something like shell access is exactly zero. For the god's sake, read the thread before posting into it. Everything has been discussed no more than two days ago. Yes, yes, I know. I wanted to react from the heart, without the intellectual baggage of knowing the technical intricacies behind the problem. D. Yes, who wants the facts to get in the way of a good emotion! ;-) -- Andrew DeFaria http://defaria.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Simplify AD integration?
Corinna Vinschen writes: - prefixed with the machine name if the machine is member of a domain. That's exactly what I am having a bit of a problem with at the moment. As discussed before, the user name sshd is hardcoded, which requires to either make it a domain account (our AD admin has at least promised to think about creating it, but of course sshd doesn't match any of the naming rules they have for such accounts) or add it to /etc/passwd with the prefix removed. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Simplify AD integration?
Corinna Vinschen writes: I'm not sure yet. I guess I'll be going for a short /etc/nsswitch.conf file containing just the default values as comments and a pointer to the documentation. Do you want this to reside in base-files? We'd have to organize a synchronized release to get rid of some of the stuff there that sets up /etc/passwd and /etc/group anyway. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Simplify AD integration?
On Aug 1 19:44, Achim Gratz wrote: Corinna Vinschen writes: I'm not sure yet. I guess I'll be going for a short /etc/nsswitch.conf file containing just the default values as comments and a pointer to the documentation. Do you want this to reside in base-files? No, I've already prepared a matching patch for the base-cygwin package. We'd have to organize a synchronized release to get rid of some of the stuff there that sets up /etc/passwd and /etc/group anyway. base-cygwin creates the /etc/passwd and /etc/group files (and the next version won't). What is base-files doing to these files? Anyway, if base-files tweaks the files, it shouldn't anymore. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpsZxkPEkRSk.pgp Description: PGP signature
Re: Simplify AD integration?
On Aug 1 10:16, Andrew DeFaria wrote: On 8/1/2014 5:28 AM, D. Boland wrote: Andrey Repin wrote: Greetings, D. Boland! I am not only a man of legacy, but also a very opinionated one. So give me some slack when I say: the whole thing is insane. This would mean that from now on, I have to use constructs like ~+daniel ~+SYSTEM in a Linux shell?? Bizarre. No, you don't have. Default domain users are unprefixed, and the chance you would use internal accounts for something like shell access is exactly zero. For the god's sake, read the thread before posting into it. Everything has been discussed no more than two days ago. Yes, yes, I know. I wanted to react from the heart, without the intellectual baggage of knowing the technical intricacies behind the problem. D. Yes, who wants the facts to get in the way of a good emotion! ;-) I apologize for throwing unnecessary technical details into the discussion :} Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpTJeuI10ySJ.pgp Description: PGP signature
Re: Simplify AD integration?
On Aug 1 19:43, Achim Gratz wrote: Corinna Vinschen writes: - prefixed with the machine name if the machine is member of a domain. That's exactly what I am having a bit of a problem with at the moment. As discussed before, the user name sshd is hardcoded, which requires to either make it a domain account (our AD admin has at least promised to think about creating it, but of course sshd doesn't match any of the naming rules they have for such accounts) or add it to /etc/passwd with the prefix removed. You don't have to care. The next version of OpenSSH comes with Cygwin-specific code. It will call cygwin_internal(CW_CYGNAME_FROM_WINNAME, sshd); to fetch the Cygwin username for the sshd account. The OpenSSH patch has already been applied upstream, the CW_CYGNAME_FROM_WINNAME functionality is in Cygwin CVS(*), available for use by any service having a similar problem. Corinna (*) https://cygwin.com/viewvc/src/winsup/cygwin/external.cc?revision=1.139view=markup#l622 -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpoVj74ZOVD1.pgp Description: PGP signature
Re: Simplify AD integration?
Corinna Vinschen writes: base-cygwin creates the /etc/passwd and /etc/group files (and the next version won't). What is base-files doing to these files? I misremembered, it currently only checks for mkpasswd, mkgroup and group_GID_clash and only warns about this and admonishes the user to run: mkpasswd -l [-d] /etc/passwd mkgroup -l [-d] /etc/group It doesn't actually run those commands. But both the warnings and the possible remedies might have to be removed or adapted. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Waldorf MIDI Implementation additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Simplify AD integration?
Corinna Vinschen writes: You don't have to care. The next version of OpenSSH comes with Cygwin-specific code. It will call cygwin_internal(CW_CYGNAME_FROM_WINNAME, sshd); to fetch the Cygwin username for the sshd account. The OpenSSH patch has already been applied upstream, the CW_CYGNAME_FROM_WINNAME functionality is in Cygwin CVS(*), available for use by any service having a similar problem. Great. If you need a guinea pig for testing, I already have the latest snapshot installed. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Simplify AD integration?
On Aug 1 20:25, Achim Gratz wrote: Corinna Vinschen writes: You don't have to care. The next version of OpenSSH comes with Cygwin-specific code. It will call cygwin_internal(CW_CYGNAME_FROM_WINNAME, sshd); to fetch the Cygwin username for the sshd account. The OpenSSH patch has already been applied upstream, the CW_CYGNAME_FROM_WINNAME functionality is in Cygwin CVS(*), available for use by any service having a similar problem. Great. If you need a guinea pig for testing, I already have the latest snapshot installed. You can download the sources from cvs -d anoncvs AT anoncvs DOT mindrot DOT org:/cvs checkout openssh For building you only need crypt and libopenssl100, everything else should be optional (in theory). Make sure to enable privilege separation. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp2cA1d7yXs6.pgp Description: PGP signature
Re: Simplify AD integration?
On Aug 1 20:22, Achim Gratz wrote: Corinna Vinschen writes: base-cygwin creates the /etc/passwd and /etc/group files (and the next version won't). What is base-files doing to these files? I misremembered, it currently only checks for mkpasswd, mkgroup and group_GID_clash and only warns about this and admonishes the user to run: mkpasswd -l [-d] /etc/passwd mkgroup -l [-d] /etc/group It doesn't actually run those commands. But both the warnings and the possible remedies might have to be removed or adapted. These fake accounts don't exist anymore. Unknown SIDs (unlikely) will return an Unknown User/Group entry, or, if db is disabled in /etc/nsswitch.conf, getpwnam and friends will return NULL. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpxqpV_B8vDu.pgp Description: PGP signature
Re: Simplify AD integration?
Corinna Vinschen writes: These fake accounts don't exist anymore. Unknown SIDs (unlikely) will return an Unknown User/Group entry, or, if db is disabled in /etc/nsswitch.conf, getpwnam and friends will return NULL. Good, then the whole section in /etc/profile can be removed. But since it doesn't get triggered anyway with the changes for ADÂ integration in place, there's alao no need to rush a release... Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Simplify AD integration?
Corinna Vinschen corinna-cygwin at cygwin.com writes: Good points. I might have overvalued the gain of easily recognizing builtin accounts by the leading '+' separator. After some thinking with my eyes closed... not prefixing local accounts at all would at least allow the sshd to see the local sshd user without jumping through hoops, so that might be a net gain after all. What I don't know: what happens if a local and a primary domain user have the same name? Regards, Achim. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Simplify AD integration?
Corinna Vinschen wrote: 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? 2. Shall we stick to '+' as the separator char or choose another one? If so, which one? 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? I'm a legacy man. So I would say keep the MS symbol and use it like this \daniel, \SYSTEM, etc. 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'? When in the Cywin domain, do like Cygwin. So, downcasing. Cheers, Daniel -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Simplify AD integration?
On 07/31/2014 07:26 AM, D. Boland wrote: Corinna Vinschen wrote: 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? 2. Shall we stick to '+' as the separator char or choose another one? If so, which one? 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? I'm a legacy man. So I would say keep the MS symbol and use it like this \daniel, \SYSTEM, etc. But you'd have to write that as '\daniel' or \\daniel in the shell, and you also cripple tilde expansion. That's why we already ruled out :, \, and / as non-starters, as mentioned elsewhere in this thread. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Simplify AD integration?
Eric Blake wrote: On 07/31/2014 07:26 AM, D. Boland wrote: Corinna Vinschen wrote: 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? 2. Shall we stick to '+' as the separator char or choose another one? If so, which one? 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? I'm a legacy man. So I would say keep the MS symbol and use it like this \daniel, \SYSTEM, etc. But you'd have to write that as '\daniel' or \\daniel in the shell, and you also cripple tilde expansion. That's why we already ruled out :, \, and / as non-starters, as mentioned elsewhere in this thread. I am not only a man of legacy, but also a very opinionated one. So give me some slack when I say: the whole thing is insane. This would mean that from now on, I have to use constructs like ~+daniel ~+SYSTEM in a Linux shell?? Bizarre. On the other hand, for the sake of progress, but keeping legacy there would be only one acceptable solution: use the tilde symbol. A user could then be referred to as: ~daniel. This already works in the shell and it is also done by the Apache webserver. If I want to go my personal web space I can type: http://localhost/~daniel/ Come to think of it: IMAP does this too! I have been coding for an IMAP project, and if you want to fetch somebody's mail, you'd have to use ~corinna to display the contents of her INBOX. Cheers, Daniel -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Simplify AD integration?
Greetings, D. Boland! I am not only a man of legacy, but also a very opinionated one. So give me some slack when I say: the whole thing is insane. This would mean that from now on, I have to use constructs like ~+daniel ~+SYSTEM in a Linux shell?? Bizarre. No, you don't have. Default domain users are unprefixed, and the chance you would use internal accounts for something like shell access is exactly zero. For the god's sake, read the thread before posting into it. Everything has been discussed no more than two days ago. -- WBR, Andrey Repin (anrdae...@yandex.ru) 01.08.2014, 02:10 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Simplify AD integration?
Corinna Vinschen corinna-cygwin at cygwin.com writes: 1. Shall we remove the leading '+' from the builtin account names or shall we keep it? I'd rather keep it since it's a good reminder where that comes from. 2. Shall we stick to '+' as the separator char or choose another one? If so, which one? WJFFM at the moment, so I don't see a pressing need for variability. 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? I'd rather keep this, although auto is all I use at the moment. BTW, would it be possible to recognize PRIMARYDOMAIN+user and (auto) user be recognized as the same thing when auto is in effect? The ability to explicitly specify the prefix even though it isn't necessarily displayed would most likely remove much of the potential need for variability in that department (and defuse the booby trap in chown). If you keep it, then there's an obvious candidate missing: local+other, which should prefix all accounts except the primary domain ones. So it'd be better to simply flag which groups to prefix, I'd think (local, primary, other) and specify this like symbolic modes in chmod, perhaps? 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'd be in favor of this since I've already had two users that wouldn't see their home directories until I figured out that they'd have their names capitalized in AD... as long as Windows is unable to distinguish users based on the case there shouldn't be a problem. Regards, Achim. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Simplify AD integration?
On Jul 30 14:38, Achim Gratz wrote: Corinna Vinschen corinna-cygwin at cygwin.com writes: 1. Shall we remove the leading '+' from the builtin account names or shall we keep it? I'd rather keep it since it's a good reminder where that comes from. 2. Shall we stick to '+' as the separator char or choose another one? If so, which one? WJFFM at the moment, so I don't see a pressing need for variability. 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? I'd rather keep this, although auto is all I use at the moment. BTW, would it be possible to recognize PRIMARYDOMAIN+user and (auto) user be recognized as the same thing when auto is in effect? The ability to explicitly specify the prefix even though it isn't necessarily displayed would most likely remove much of the potential need for variability in that department I'm not sure if that would work as expected. Cygwin explicitely tests if the account name follows the current rule. I'm not so sure what effects it would have, if getpwnam could return another username as the one given as parameter (apart from the case difference). (and defuse the booby trap in chown). Well, hmm. If we allow to specify NT AUTHORITY+SYSTEM or BUILTIN+Administrators even in auto or primary mode... Unfortunately this won't help in all cases. I used a broken example :( The LOCAL account and a few others have NO domain. Thus, they are simply +-prefixed (+LOCAL), even in 'db_prefix: always' mode. Tricky. If you keep it, then there's an obvious candidate missing: local+other, which should prefix all accounts except the primary domain ones. Do you mean builtin accounts; NT AUTHORITY+SYSTEM, BUILTIN+Administrators, ... primary domain corinna, cgf, ... other domain: DOMAIN1+walter, DOMAIN2+mathilda ? So it'd be better to simply flag which groups to prefix, I'd think (local, primary, other) and specify this like symbolic modes in chmod, perhaps? 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'd be in favor of this since I've already had two users that wouldn't see their home directories until I figured out that they'd have their names capitalized in AD... as long as Windows is unable to distinguish users based on the case there shouldn't be a problem. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp4vKFQSO1cb.pgp Description: PGP signature
Re: Simplify AD integration?
On 30.07.2014 15:47, Corinna Vinschen wrote: Hi folks, here's a set of question to those of you interested in the new passwd/group functionality. This already has been discussed partially, but there was no conclusion. Right now, there's a lot of variability in the user names, based on the /etc/nsswitch.conf settings db_prefix and db_separator. The separator char is a '+' by default but can be replaced with other ASCII chars. db_prefix allows three styles of user naming conventions: Default is 'auto': builtin accounts; +SYSTEM, +LOCAL, etc. primary domain corinna, cgf, ... other domain: DOMAIN1+walter, DOMAIN2+mathilda If set to 'primary': builtin accounts; +SYSTEM, +LOCAL, etc. primary domain MYDOMAIN+corinna, MYDOMAIN+cgf, ... other domain: DOMAIN1+walter, DOMAIN2+mathilda If set to 'always': builtin accounts; NT AUTHORITY+SYSTEM, BULTIN+LOCAL, etc. primary domain MYDOMAIN+corinna, MYDOMAIN+cgf, ... other domain: DOMAIN1+walter, DOMAIN2+mathilda Primary domain here is either the primary domain of the machine or the local SAM if the machine is no domain member. Other domain here is either a trusted domain or the local SAM for domain machines. Together with the variable separator char this is an awful lot of variability, which has the potential side effect to complicate the code *and* debugging. 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. 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? 2. Shall we stick to '+' as the separator char or choose another one? If so, which one? 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? 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'? Thanks, Corinna Just a thought: Is there anything preventing you from using the pathname conventions for user names? I seem to remember having seen constructs like domain/user (or ./user for the local domain) e.g. in Samba and found this to be quite intuitive, up to and including the ability to drop a leading ./ for local names. It is also pretty close to how Windows specifies domain users names (but use the unixy '/' instead of the windozy '\' (or must I write '\\' ;-)) and positively avoids the chown gotcha. Also some code could be reused for user name handling from path canonicalization? Again - I'm not deep into this topic, so please feel free to ignore the suggestion if it doesn't make sense to you. Cheers, Wolf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Simplify AD integration?
On Jul 30 17:29, Wolf Geldmacher wrote: Just a thought: Is there anything preventing you from using the pathname conventions for user names? I seem to remember having seen constructs like domain/user (or ./user for the local domain) e.g. in Samba and found this to be quite intuitive, up to and including the ability to drop a leading ./ for local names. Consider: export USER=domain/user export HOME=/home/$USER cd $HOME cd ~domain/userTAB This opens another can of worms. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp3r2LfFbOpL.pgp Description: PGP signature
Re: Simplify AD integration?
Corinna Vinschen writes: I'm not sure if that would work as expected. Cygwin explicitely tests if the account name follows the current rule. I'm not so sure what effects it would have, if getpwnam could return another username as the one given as parameter (apart from the case difference). That could be a problem if an application checks for that, but then there's only a handful of cases where you'd want to use an explicitly prefixed user or group name. (and defuse the booby trap in chown). Well, hmm. If we allow to specify NT AUTHORITY+SYSTEM or BUILTIN+Administrators even in auto or primary mode... Unfortunately this won't help in all cases. I used a broken example :( The LOCAL account and a few others have NO domain. Thus, they are simply +-prefixed (+LOCAL), even in 'db_prefix: always' mode. We could invent one, for the sole reason to escape the leading +. Tricky. Certainly… If you keep it, then there's an obvious candidate missing: local+other, which should prefix all accounts except the primary domain ones. Do you mean builtin accounts; NT AUTHORITY+SYSTEM, BUILTIN+Administrators, ... primary domain corinna, cgf, ... other domain: DOMAIN1+walter, DOMAIN2+mathilda Yes. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Simplify AD integration?
bin69uSzBU_dV.bin Description: PGP/MIME version identification encrypted.asc Description: OpenPGP encrypted message
Re: Simplify AD integration?
On 07/30/2014 09:47 AM, Corinna Vinschen wrote: Hi folks, here's a set of question to those of you interested in the new passwd/group functionality. This already has been discussed partially, but there was no conclusion. Right now, there's a lot of variability in the user names, based on the /etc/nsswitch.conf settings db_prefix and db_separator. The separator char is a '+' by default but can be replaced with other ASCII chars. db_prefix allows three styles of user naming conventions: Default is 'auto': builtin accounts; +SYSTEM, +LOCAL, etc. primary domain corinna, cgf, ... other domain: DOMAIN1+walter, DOMAIN2+mathilda If set to 'primary': builtin accounts; +SYSTEM, +LOCAL, etc. primary domain MYDOMAIN+corinna, MYDOMAIN+cgf, ... other domain: DOMAIN1+walter, DOMAIN2+mathilda If set to 'always': builtin accounts; NT AUTHORITY+SYSTEM, BULTIN+LOCAL, etc. primary domain MYDOMAIN+corinna, MYDOMAIN+cgf, ... other domain: DOMAIN1+walter, DOMAIN2+mathilda Primary domain here is either the primary domain of the machine or the local SAM if the machine is no domain member. Other domain here is either a trusted domain or the local SAM for domain machines. Together with the variable separator char this is an awful lot of variability, which has the potential side effect to complicate the code *and* debugging. 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. 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'd say remove it since it isn't providing a clear benefit and, more importantly, causes regressions in some cases with existing tools (as you stated above with chown). 2. Shall we stick to '+' as the separator char or choose another one? If so, which one? Did the discussion of this before end up inconclusive? I thought that '+' was seen as preferable for some reason that received some overall approval. 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? My opinion is that options are only necessary when there's no clear single solution. If it's very clear that there is no way to merge all these possibilities into 1 or one is not clearly a superset of the others, then we need to keep the options. We shouldn't keep the options just to have options obviously. :-) 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'? This is enticing since it's a more common convention for UNIX/Linux environments, which Cygwin strives to mimic. But I would say that downcasing isn't desirable since it just upholds a convention. The convention isn't a requirement so it shouldn't be enforced. -- Larry _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Simplify AD integration?
binBrUF88cEjA.bin Description: PGP/MIME version identification encrypted.asc Description: OpenPGP encrypted message
Re: Simplify AD integration?
[resent; no idea why gpg tried to encrypt my first attempt] On 07/30/2014 09:29 AM, Wolf Geldmacher wrote: Is there anything preventing you from using the pathname conventions for user names? Yes, we already discussed and dismissed that as too painful. Tilde-expansion in the shell would be broken (you can't get ~domain/user/file to expand into /path/to/users_home/file, because the shell tries to treat it as /path/to/domains_home/user/file). Colon is equally bad, since 'chown domain:user:domain:group' is unparseable. 'chown domain+user:domain+group' is at least reasonable. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Simplify AD integration?
[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. 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. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Simplify AD integration?
On 7/30/2014 6:47 AM, Corinna Vinschen wrote: I have not been actively watching this thread but if I'm correct we're adding NIS like capabilities to Cygwin so that /etc/passwd can easily be filled with say everybody in the domain? If so then bravo! I also take it that it's not ready yet either. When it is, how would I install it? 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? 2. Shall we stick to '+' as the separator char or choose another one? If so, which one? How about @? 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? 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 say downshift them! -- Andrew DeFaria http://defaria.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Simplify AD integration?
On Jul 30 11:15, Andrew DeFaria wrote: On 7/30/2014 6:47 AM, Corinna Vinschen wrote: I have not been actively watching this thread but if I'm correct we're adding NIS like capabilities to Cygwin so that /etc/passwd can easily be filled with say everybody in the domain? If so then bravo! I also take it that it's not ready yet either. It's ready for a given value of ready. I'm just looking for certain details which needs to be clarified before the stuff can be released. When it is, how would I install it? The existing code is in almost all developer snapshots of the last few months. Just try the last one from http://cygwin.com/snapshots/ and read my preliminary documentation attached to this mail again (and which, incidentally, is now in the offical docs in the repo as well). 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? 2. Shall we stick to '+' as the separator char or choose another one? If so, which one? How about @? Dunno. It *might* be a good alternative to '+'. Personally I just dislike that a '@' is a less light character and it might give a wrong idea. Email: name AT domain. Cygwin account: domain AT name. 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? 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 say downshift them! Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp7Iku51Wvvn.pgp Description: PGP signature
Re: Simplify AD integration?
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, hm, *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
Re: Simplify AD integration?
On Jul 30 20:40, Corinna Vinschen wrote: On Jul 30 11:15, Andrew DeFaria wrote: On 7/30/2014 6:47 AM, Corinna Vinschen wrote: I have not been actively watching this thread but if I'm correct we're adding NIS like capabilities to Cygwin so that /etc/passwd can easily be filled with say everybody in the domain? If so then bravo! I also take it that it's not ready yet either. It's ready for a given value of ready. I'm just looking for certain details which needs to be clarified before the stuff can be released. When it is, how would I install it? The existing code is in almost all developer snapshots of the last few months. Just try the last one from http://cygwin.com/snapshots/ and read my preliminary documentation attached to this mail again Sorry. Attached to *this* mail. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat === History === For as long as Cygwin has existed, it has stored user and group information in /etc/passwd and /etc/group files. Under the assumption that these files would never be too large, the first process in a process tree, as well as every execing process within the tree would parse them into structures in memory. Thus every Cygwin process would contain an expanded copy of the full information from /etc/passwd and /etc/group. This approach has a few downsides. One of them is that the idea to have always small files is flawed. Another one is that reading the entire file is most of the time entirely useless, since most processes only need information on their own user and the primary group. Last but not least, the passwd and group files have to be maintained separately from the already existing Windows user databases, the local SAM and Active Directory. On the other hand, we have to have a mapping between Windows SIDs and POSIX uid/gid values (see [1]), so we rely on some mechanism to convert SIDs to uid/gid values and vice versa. Microsoft Services for UNIX (SFU) (which are unfortunately deprecated since Windows 8/Server 2012) never used passwd/group files. Rather, SFU used a fixed, computational mapping between SIDs and POSIX uid/gid. It allows to generate uid/gid values from SIDs and vice versa. The mechanism is documented, albeit in a confusing way and spread over multiple MSDN articles. The Cygwin approach clones the mapping, with just tiny differences for backward compatibility. = How does it work? = The following description assumes you're comfortable with the concept of Windows SIDs and RIDs. For a brief introduction, please read [1]. Cygwin's new mapping between SIDs and uid/gid values works in two ways. - Read /etc/passwd and /etc/group files, like before, mainly for backward compatibility. - If no files are present, or if an entry is missing in the files, ask Windows. At least, that's the default behaviour now. It will be configurable using a file /etc/nsswitch.conf, which is discussed in a later section. Let's explore the default for now. If files are present, they will be scanned on demand as soon as a mapping from SIDs to uid/gid or account names is required. The new mechanism will never read the entire file into memory, but only scan for the requested entry and cache this one in memory[2]. If no entry is found, or no passwd or group file was present, Cygwin will ask the OS. Note: If the first process in a Cygwin process tree determines that no /etc/passwd or /etc/group file is present, no other process in the entire process tree will try to read the files later on. This is done for self-preservation. It's rather bad if the uid or gid of a user changes during the lifetime of a process tree. For the same reason, if you delete the /etc/passwd or /etc/group file, this will be ignored. The passwd and group records read from the files will persist in memory until either a new /etc/passwd or /etc/group files is created, or you exit all processes in the current process tree. See the note in the section on /etc/nsswitch.conf for some comprehensive examples. So if we've drawn a blank reading the files, we're going to ask the OS. First thing, we ask the local machine for the SID or the username. The OS functions LookupAccountSid and LookupAccountName[3] are pretty intelligent. They have all the stuff built in to ask for any account of the local machine, the Active Directory domain of the machine, the Global Catalog of the forest of the domain, as well as any trusted domain of our forest for the information. One OS call and we're practically done... Except, the calls only return the mapping between SID, account name and the account's domain. We don't have a mapping to POSIX uid/gid and we're missing information on the user's home dir and login shell. Let's discuss the SID=uid/gid
Re: Simplify AD integration?
On 07/30/2014 12:40 PM, Corinna Vinschen wrote: 2. Shall we stick to '+' as the separator char or choose another one? If so, which one? How about @? Dunno. It *might* be a good alternative to '+'. Personally I just dislike that a '@' is a less light character and it might give a wrong idea. Email: name AT domain. Cygwin account: domain AT name. How bad would it be to treat the window's DOMAIN\user as cygwin user@DOMAIN? Yes, it means string-splicing to rearrange strings when converting between the two forms, rather than just single-character replacement, but it might work. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
RE: Simplify AD integration?
Eric Blake writes: How bad would it be to treat the window's DOMAIN\user as cygwin user@DOMAIN? Yes, it means string-splicing to rearrange strings when converting between the two forms, rather than just single-character replacement, but it might work. Sounds reasonable to me. Consider also that modern(*) Windows recognizes (prefers?) user@domain as equivalent to domain\user in places. For example, when I log on, I can use either form in the user/ password dialog. stephan(); (*) I use Windows 7 and 8
Re: Simplify AD integration?
On Jul 30 13:09, Eric Blake wrote: On 07/30/2014 12:40 PM, Corinna Vinschen wrote: 2. Shall we stick to '+' as the separator char or choose another one? If so, which one? How about @? Dunno. It *might* be a good alternative to '+'. Personally I just dislike that a '@' is a less light character and it might give a wrong idea. Email: name AT domain. Cygwin account: domain AT name. How bad would it be to treat the window's DOMAIN\user as cygwin user@DOMAIN? Yes, it means string-splicing to rearrange strings when converting between the two forms, rather than just single-character replacement, but it might work. It's more or less simple from a coding perspective, slightly more complicated when evaluating the incoming name in a call to getpwnam/getgrnam. But I'm concerned that using this form is worse than DOMAIN@user. As you know, starting with Active Directory in Windows 2000, there are two variations of the domain name. The first is the Netbios domain name as used in pre-Windows 2000 already. It's called flat name and it consist of alphanumeric chars only. The Windows expression for this type of username is FLATEXAMPLE\user. The second, more modern is the DNS-type domain name. In this case the domain name is a DNS-style name like example.com. A username in this style is written like a email address (trying to workaround the mailing list filters) user AT example DOT com. You can use this style to login to your machine, for instance. FLATEXAMPLE and example.com are the same domain, just two different names for the same thing. LookupAccountSid and LookupAccountName return the FLATEXAMPLE domain and that's used in the Cygwin username. If you start using the FLATEXAMPLE domain in the writing style of the DNS-style domain, I can see a lot of confusion coming up. This does in no way reflect what the users use with native Windows. name @ FLATEXAMPLE?!? Shouldn't that be name AT example DOT com? OTOH, if we use the DNS-style name as username, we introduce an even more complex naming scheme on the commandline, with additional dots. I'm not sure how useful that is. Does that make sense? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpkJQ9CsX_zq.pgp Description: PGP signature
Re: Simplify AD integration?
On Jul 30 19:23, Stephan Mueller wrote: Eric Blake writes: How bad would it be to treat the window's DOMAIN\user as cygwin user@DOMAIN? Yes, it means string-splicing to rearrange strings when converting between the two forms, rather than just single-character replacement, but it might work. Sounds reasonable to me. Consider also that modern(*) Windows recognizes (prefers?) user@domain as equivalent to domain\user in places. No, no! It's not the same. I just wrote about that in my reply to Eric. It's FLATDOMAIN\user vs. user@dnsdomain These are different strings referring to the same domain. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp4PWdDosRki.pgp Description: PGP signature
Re: Simplify AD integration?
Eric Blake writes: 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 +. The set of usable characters also includes '=' I suppose (plus '@' as has been mentioned elsewhere in the thread). They'd both work as leading character for local accounts I'd think. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Simplify AD integration?
On Jul 30 21:29, Corinna Vinschen wrote: On Jul 30 13:09, Eric Blake wrote: On 07/30/2014 12:40 PM, Corinna Vinschen wrote: 2. Shall we stick to '+' as the separator char or choose another one? If so, which one? How about @? Dunno. It *might* be a good alternative to '+'. Personally I just dislike that a '@' is a less light character and it might give a wrong idea. Email: name AT domain. Cygwin account: domain AT name. How bad would it be to treat the window's DOMAIN\user as cygwin user@DOMAIN? Yes, it means string-splicing to rearrange strings when converting between the two forms, rather than just single-character replacement, but it might work. It's more or less simple from a coding perspective, slightly more complicated when evaluating the incoming name in a call to getpwnam/getgrnam. But I'm concerned that using this form is worse than DOMAIN@user. As you know, starting with Active Directory in Windows 2000, there are two variations of the domain name. The first is the Netbios domain name as used in pre-Windows 2000 already. It's called flat name and it consist of alphanumeric chars only. The Windows expression for this type of username is FLATEXAMPLE\user. The second, more modern is the DNS-type domain name. In this case the domain name is a DNS-style name like example.com. A username in this style is written like a email address (trying to workaround the mailing list filters) user AT example DOT com. You can use this style to login to your machine, for instance. FLATEXAMPLE and example.com are the same domain, just two different names for the same thing. LookupAccountSid and LookupAccountName return the FLATEXAMPLE domain and that's used in the Cygwin username. If you start using the FLATEXAMPLE domain in the writing style of the DNS-style domain, I can see a lot of confusion coming up. This does in no way reflect what the users use with native Windows. name @ FLATEXAMPLE?!? Shouldn't that be name AT example DOT com? OTOH, if we use the DNS-style name as username, we introduce an even more complex naming scheme on the commandline, with additional dots. I'm not sure how useful that is. Also, chown just occured to me. Think `chown user.group file' with the username containing dots. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpljXHX8y4FO.pgp Description: PGP signature
Re: Simplify AD integration?
On 7/30/2014 11:40 AM, Corinna Vinschen wrote: On Jul 30 11:15, Andrew DeFaria wrote: On 7/30/2014 6:47 AM, Corinna Vinschen wrote: When it is, how would I install it? The existing code is in almost all developer snapshots of the last few months. Just try the last one from http://cygwin.com/snapshots/ and read my preliminary documentation attached to this mail again (and which, incidentally, is now in the offical docs in the repo as well). I guess I was just curious as to what the package name might be... NIS? AD or ActiveDirectory or CygwinUserIntegration... How about @? Dunno. It *might* be a good alternative to '+'. Personally I just dislike that a '@' is a less light character and it might give a wrong idea. Email: name AT domain. Cygwin account: domain AT name. Yeah I wish we could switch it to name@domain... -- Andrew DeFaria http://defaria.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Simplify AD integration?
On 07/30/2014 04:04 PM, Andrew DeFaria wrote: On 7/30/2014 11:40 AM, Corinna Vinschen wrote: On Jul 30 11:15, Andrew DeFaria wrote: On 7/30/2014 6:47 AM, Corinna Vinschen wrote: When it is, how would I install it? The existing code is in almost all developer snapshots of the last few months. Just try the last one from http://cygwin.com/snapshots/ and read my preliminary documentation attached to this mail again (and which, incidentally, is now in the offical docs in the repo as well). I guess I was just curious as to what the package name might be... NIS? AD or ActiveDirectory or CygwinUserIntegration... The implementation is part of the Cygwin DLL so it lives in the cygwin package. That's why Corinna was directing you towards the Cygwin snapshots page. -- Larry _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Simplify AD integration?
On 7/30/2014 1:48 PM, Larry Hall (Cygwin) wrote: On 07/30/2014 04:04 PM, Andrew DeFaria wrote: On 7/30/2014 11:40 AM, Corinna Vinschen wrote: On Jul 30 11:15, Andrew DeFaria wrote: On 7/30/2014 6:47 AM, Corinna Vinschen wrote: When it is, how would I install it? The existing code is in almost all developer snapshots of the last few months. Just try the last one from http://cygwin.com/snapshots/ and read my preliminary documentation attached to this mail again (and which, incidentally, is now in the offical docs in the repo as well). I guess I was just curious as to what the package name might be... NIS? AD or ActiveDirectory or CygwinUserIntegration... The implementation is part of the Cygwin DLL so it lives in the cygwin package. That's why Corinna was directing you towards the Cygwin snapshots page. Ah yes. That makes sense I guess. But does this mean that things will come in with the base package like /etc/nsswitch.conf, etc? -- Andrew DeFaria http://defaria.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Simplify AD integration?
Greetings, Corinna Vinschen! Do you mean builtin accounts; NT AUTHORITY+SYSTEM, BUILTIN+Administrators, ... primary domain corinna, cgf, ... other domain: DOMAIN1+walter, DOMAIN2+mathilda That sounds about right to me. So it'd be better to simply flag which groups to prefix, I'd think (local, primary, other) and specify this like symbolic modes in chmod, perhaps? 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'd be in favor of this since I've already had two users that wouldn't see their home directories until I figured out that they'd have their names capitalized in AD... as long as Windows is unable to distinguish users based on the case there shouldn't be a problem. I've got my lesson learned since I've tried to set up authorization server for a wide range of devices at once. Since then, I _always_ make user names lowercase. And pure alphabetic. So, I wouldn't notice a difference. -- WBR, Andrey Repin (anrdae...@yandex.ru) 31.07.2014, 02:01 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Simplify AD integration?
Greetings, Andrew DeFaria!
When it is, how would I
install it?
The existing code is in almost all developer snapshots of the last few
months. Just try the last one from http://cygwin.com/snapshots/ and
read my preliminary documentation attached to this mail again (and
which, incidentally, is now in the offical docs in the repo as well).
I guess I was just curious as to what the package name might be...
NIS? AD
or ActiveDirectory or CygwinUserIntegration...
The implementation is part of the Cygwin DLL so it lives in the cygwin
package. That's why Corinna was directing you towards the Cygwin snapshots
page.
Ah yes. That makes sense I guess. But does this mean that things will
come in with the base package like /etc/nsswitch.conf, etc?
No(*), but you may use it.
*) No in sense that it will work with default settings out of the box, at
maximum providing a template /etc/nsswitch.conf file for possible
customization.
Right now, I'm running with bare hands (no /etc/{nsswitch.conf,passwd,group}).
And I like how it works so far.
--
WBR,
Andrey Repin (anrdae...@yandex.ru) 31.07.2014, 02:12
Sorry for my terrible english...
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Simplify AD integration?
On 07/30/2014 05:19 PM, Andrew DeFaria wrote: snip Ah yes. That makes sense I guess. But does this mean that things will come in with the base package like /etc/nsswitch.conf, etc? Right now, the documentation hints that it's up to the user to create this file. Whether there will be a configure script at some point to help create a first version, that's something for Corinna to comment on. -- Larry _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
