* Simplify AD integration? @ 2014-07-30 13:47 Corinna Vinschen 2014-07-30 14:38 ` Achim Gratz ` (7 more replies) 0 siblings, 8 replies; 53+ messages in thread From: Corinna Vinschen @ 2014-07-30 13:47 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 2573 bytes --] 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 -- 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 --] ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Simplify AD integration? 2014-07-30 13:47 Simplify AD integration? Corinna Vinschen @ 2014-07-30 14:38 ` Achim Gratz 2014-07-30 15:01 ` Corinna Vinschen 2014-07-30 15:29 ` Wolf Geldmacher ` (6 subsequent siblings) 7 siblings, 1 reply; 53+ messages in thread From: Achim Gratz @ 2014-07-30 14:38 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Simplify AD integration? 2014-07-30 14:38 ` Achim Gratz @ 2014-07-30 15:01 ` Corinna Vinschen 2014-07-30 16:33 ` Achim Gratz 2014-07-30 22:05 ` Andrey Repin 0 siblings, 2 replies; 53+ messages in thread From: Corinna Vinschen @ 2014-07-30 15:01 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 2850 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Simplify AD integration? 2014-07-30 15:01 ` Corinna Vinschen @ 2014-07-30 16:33 ` Achim Gratz 2014-07-30 22:05 ` Andrey Repin 1 sibling, 0 replies; 53+ messages in thread From: Achim Gratz @ 2014-07-30 16:33 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Simplify AD integration? 2014-07-30 15:01 ` Corinna Vinschen 2014-07-30 16:33 ` Achim Gratz @ 2014-07-30 22:05 ` Andrey Repin 1 sibling, 0 replies; 53+ messages in thread From: Andrey Repin @ 2014-07-30 22:05 UTC (permalink / raw) To: Corinna Vinschen 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 (anrdaemon@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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Simplify AD integration? 2014-07-30 13:47 Simplify AD integration? Corinna Vinschen 2014-07-30 14:38 ` Achim Gratz @ 2014-07-30 15:29 ` Wolf Geldmacher 2014-07-30 15:43 ` Corinna Vinschen ` (2 more replies) 2014-07-30 17:11 ` Larry Hall (Cygwin) ` (5 subsequent siblings) 7 siblings, 3 replies; 53+ messages in thread From: Wolf Geldmacher @ 2014-07-30 15:29 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Simplify AD integration? 2014-07-30 15:29 ` Wolf Geldmacher @ 2014-07-30 15:43 ` Corinna Vinschen 2014-07-30 17:00 ` Eric Blake 2014-07-30 18:10 ` Eric Blake 2 siblings, 0 replies; 53+ messages in thread From: Corinna Vinschen @ 2014-07-30 15:43 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 698 bytes --] 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/user<TAB> This opens another can of worms. 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 --] ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Simplify AD integration? 2014-07-30 15:29 ` Wolf Geldmacher 2014-07-30 15:43 ` Corinna Vinschen @ 2014-07-30 17:00 ` Eric Blake 2014-07-30 18:10 ` Eric Blake 2 siblings, 0 replies; 53+ messages in thread From: Eric Blake @ 2014-07-30 17:00 UTC (permalink / raw) To: cygwin [-- Attachment #1: PGP/MIME version identification --] [-- Type: application/pgp-encrypted, Size: 11 bytes --] [-- Attachment #2: OpenPGP encrypted message --] [-- Type: application/octet-stream, Size: 2059 bytes --] -----BEGIN PGP MESSAGE----- Version: GnuPG v1 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg hQIMA/cs3wc1mtB+AQ//RZvgD6MpLnGnj1Tg65sIrKfk54MZ0Kr4x9KpbjkCB8Pt 1ZUa06oVtsnt2zo+8sABzKJ59bQwq+0oGB46iE2nA0Srjkf8lmww23/PJLAe1Hz/ m1WyRtWJP3M1SFb93zX8fB4tEokC3hthUjP5iDYwhNRrck5V2CoBUheGjKTlaEa/ e0a8oLNP7dILJrtiIvt99zR/BqaFGjOXBDQ57Vi6e5REgUqIWLbG9C4JzTddfg5Y P9D+Va8b56D7Mv8/VwLWusaa+bp75FKGumToqmS8LNHWi2ydmgCr5ELzz0hqy6uD SNwr7Y0JS7b9tQaHePTaKo9L+Jxe4Xb03lBQDIuyIg2MHJ1oLOpjZCa1pl+Jio6T T/PX6aOcnNWeMqcktNWijAPLhyMGOzALDWaGgX6jX+gexfefo80BrRCf/Eg/l9De 7ZGrjkmaZdg1zj8zy2UoOZKDv6uOvxMsa/SN2HgPEpHz36X1zvM0rBeZVe0vJq0d oLilsBxTnCgi1LTEhy2VygYCc+ngqk4kNluUE8ViNQzwqecCqflCfsHD0jSQeNTK 5zdqHKqUv8rkeNVPdv3APZqQ9z97b46r+Gg95p8GecPxo/YGOrgdj2IQKVi4EUZs 5vBniurjn6OJd7m7jf9wEjI0Gl2jzM2euQXOgjsv/4cEFFNEIaqhPmsICIOJXiWF AQwD0gUcL9LkcmwBB/0aBle2Yxd5IStjCVwu/ii/+IbQA7hUIU4MIBBBt2YUhM0Z iiY8J1bjzNLivo4QexsYYwl1cTOKzQfOQTA1kNcRW4pjSLn6MB308xrZfr1foWoO yetcpRBejfk5+k8YhrwHxkG4h0dN8tTUhYf0YWpTChqCcIhHAbSHoMkNLwO7kV7j IS9eLRw85al2vygPE0wOmOwohSHLPG5zoQQRrrxyyxDKZSi/hMOIZxIBypzdNpPM Xj0mt/HSermEpwamszdfc0TJRw3REHNH3xkhl5/ZME4Jv3QANpB/Jru76BotV1ap A7I6Ubz7TmjgLOFil9OIqFzFcanh8HW3L01e1IQ30ukBdYvId7LWfa5dIgt0Zi1z 7tYFOeQCvnExtpe64rYVeVJe4mudBSxielw0BqKriu0K00zoPfVO1IKJIWyjWCw0 80GVMvatAvdiKAOPuOEluzAP4DszYYlFhaBSg1ixJXr8xmwWohazPq5Yw6lkQd/m u6ouVUuAlztOXQybKQ56/spory6j4sjpQtjuRxD1juuhvZ80n+7GvuLRtnHdeemT cvKjLjcOVwhowXghcSKGCsLpt7umrSW/u5ajQ4gmBbJgRh2QcDnQE71skacHYbmd FawdjUMXJ2tmQrp4N4VQdFWLmPZpA1LXMdclQJLe/7o9kNw1mMaKZKLxFPYNRI/I b/koJ4dmfyGHXITFUMCgb+rkIngnGQZrU5axo41kXdoERUNPlwz0WEPpXC9sxXb/ pb/Brzvo9GCUgu4kmYBvuYutFFZhnvts03TNpuxWcTliMK0BoOBbNk59NjBl6pHu zikRzoG0lKoNppzgc6NRHu5PZ560ekbJRYtFqMCTaij5DCn/SfjgI5yISXhrkVvx po+fVX7ze9ZAKQVRaJxLkVvUQciTd1Oa4d/IKC6TYi5xttFXTRrKSqGnL6elHE7a 0phX5epS7B9G4x7Yv5QdUA0Vyqrdo8zt0toroPMGGuHGwMv7pLwzhae21YbWbzh6 6wGUXohdlbOf2FjTTlxZGWJ1/juGrzYPKnCAz/XcMS5vTvX70jzpMHEL5dO9TJ1k gtJcgTZe3sReygwruBCVLLh1+VXZUHKS3mKtzbdugQcV09R+PTcEYFKIRvPN53kU SNN19U5lkvq8bqG/ISxlY3g76w== =dyEq -----END PGP MESSAGE----- ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Simplify AD integration? 2014-07-30 15:29 ` Wolf Geldmacher 2014-07-30 15:43 ` Corinna Vinschen 2014-07-30 17:00 ` Eric Blake @ 2014-07-30 18:10 ` Eric Blake 2 siblings, 0 replies; 53+ messages in thread From: Eric Blake @ 2014-07-30 18:10 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 720 bytes --] [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 [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 539 bytes --] ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Simplify AD integration? 2014-07-30 13:47 Simplify AD integration? Corinna Vinschen 2014-07-30 14:38 ` Achim Gratz 2014-07-30 15:29 ` Wolf Geldmacher @ 2014-07-30 17:11 ` Larry Hall (Cygwin) 2014-07-30 17:28 ` Eric Blake ` (4 subsequent siblings) 7 siblings, 0 replies; 53+ messages in thread From: Larry Hall (Cygwin) @ 2014-07-30 17:11 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Simplify AD integration? 2014-07-30 13:47 Simplify AD integration? Corinna Vinschen ` (2 preceding siblings ...) 2014-07-30 17:11 ` Larry Hall (Cygwin) @ 2014-07-30 17:28 ` Eric Blake 2014-07-30 18:10 ` Eric Blake ` (3 subsequent siblings) 7 siblings, 0 replies; 53+ messages in thread From: Eric Blake @ 2014-07-30 17:28 UTC (permalink / raw) To: cygwin [-- Attachment #1: PGP/MIME version identification --] [-- Type: application/pgp-encrypted, Size: 11 bytes --] [-- Attachment #2: OpenPGP encrypted message --] [-- Type: application/octet-stream, Size: 4695 bytes --] -----BEGIN PGP MESSAGE----- Version: GnuPG v1 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg hQIMA/cs3wc1mtB+AQ/+Jt8uBoEFflX0aRtXU7ccni/xhv4eBpYq97H0//HlDNew BZUWi/M3JpnaR6PVBxi9HGhwGpCXR5ycc98QWXqVSZuZSBufShtGGsI8IsSQoYqK 1cILRhTCM2C4saMKAcwxCSROQaLTtefsphONxJNaXWtw5zYyNhhXzSVGOuRH/fY6 wgNQv5tZyen0kxm6/Or5Dg1/KIUlQCdrvOaGrquUMkoaS0VdYeTcXQdghJrfrAWy S2jvjIsJtC0T+2SJU5iHGhT7D74+Bv5Bl2HsnJTyjkZFnL50pvxLjj00QnpnAOJN pyLhnSBMvN6VmNfz/zf6uuUpOj8zqThPNZvPf8B4yMMNd1e12DojjzFDErC6jBwW 1OKX73ijwmli0Abwet/kTGuEUTpeaSRH2NRwjBAW1l/a9V4/BUoZHU7p/rmRzxRK JPClljHG100NGB7IyJnsURmwFcJ89FFhq5TW1yDkj2K9iWWeMM8SRlPrgC0zCnQd W89nsFMk09oyGtmVIm4lPwP9ZHEh4g+RsIB8uwFLf+HjteB4CiVy4yOr7CanfOCa CyYk2Z+Pj6IQJM0U538OsBPCREOOdU5w4FH5I3sNB7HVaba18KZmvU6/8hmOLuDs 87/Yl5jfSVTe/G1gg9RxTWeWyxSIhvmHQLjZoAXrfbM1rnHC6iFDRJaZ46s/1QmF AQwD0gUcL9LkcmwBCAC/3l1VkUrgoKkGWaPb16Tw6WG/W2yOUrNz8iZAn0rNojaQ 5SOwZbDPHORG6sJOzrrobknL3iugRstC6aXYGBNhToX2Do+KX2PF5ztptW9ISfyE MR/c73tXG8clqVU2gUB+BX2RpgZ465QR08Pdqt45EDLxJ45R3B6aDsp9pStz6CYE Pt+yzInJy4Mck7vhxHdsodgRbYgyeCIw4ZyL84pSiAZnEgSKjzg4u4yy+b3STLpF +0L3fCbGEgGgEOdMuGKDXag7xKeB5BWAGQchwTyrNu+gbCg5P9rCKqpD7YuAUrad lHZOfPW9L1jbFCiUGKAZWBTWH/IwaauUxwkF4zWx0usBCwFc3c7R9d55R93SH6uG J1vOFAMEx3LjJlJ6E8v+Ul1nl3Iw7nnzRu9UnoqOfxbUFrW3DN7NOCw/GsLDr/Ae 4oGTYtXk7C32mJkP3RR5FjhlC9oXtf36lnn1uKtjTqocwpUXRkD6h8PMODErcRQ3 pHT4rCb9ylphOdpo8WOnQZ/fadwWeV86FJkk025/zTGNRUCawTJcW0Aui5qtyyko UlPNNUzyUFWEc3RnnL/Y4gC53Ea3Te7zTO4jGTE5S0fYjVBzyJgokq5/xtPueMoH 5LgA4nGkFD/lFZv7YonZ92GAU5TIlIUWpy0MArx0trl4H7SoslccbX1A4aC73+1q /Xa3cWmRk+Bhpa0ezJ1nMlUqRfCkyAy6oe1OpSedqMdNNqppWxdUv/DsiyFqfgaW aqhFOl6S5eFcovjWBwuWXRML9NrrTaIQuGE4w2z3e7Zht89rTYIjViIg75/aeuyh Xha5vqHLfAmVeqGCv7z+CWmks4Tz9T7s/8/H16cdL3n3prP0dGKWGLmrkvRplozw J5nZMMQoxhGOaQJnJA3uhdr9oAr6KOvY1/u8SQXBqrVKse7vjsuF0GdXca0HrL4E Wql6rJv4/yVYhlnxi8Io57xQURC85Owiw6JLCR4br2if1McCjJYpcVeYkRdUf5HQ 5chp+qLcTnhmoesa+v4zdSrIfskdLqFhg2ZLX016rwzKYth2wQ1vMCFFmG9JPCiN YqaNeMoW8tUOyUsi8XuPGjDnHuYMt4TtGW5g/P2fDqnvf5Bhjy5W+bdtiEjj+7/y DQ7lFKSYQ6UiUQPH21netlNY3Strp0REPXPGp3S7xd2eByXRu0unHa+dYh7zhsiH s2Jmt5rYUJZb3faWKGAvyMPovRgBsYPgtpatI9RlY3OeUE0sj9RdVKmnC+xSleFB nFbF9nOGUaGYewubPkCtN1LCveXMSFeGFc3sQHL4MQOg3O9MTWxWGNRg9gotdhZ/ UpGjMLB9P3Tyga21U5Z/4i2wesytBXv0innbu1NFcv72IeQs1vcvQyQmd7YXZ7/K 31PuZFxSMrvJ86buSpxEXErb6BpZBujFzcRnDUhKyAx5rZDLcoB3NqZanYRxo2++ KQbyYJoKrtGN1hhJbZKjdH1/Zc+5c7vLGwLgi3bDYHLwTSo8pofir9C8Ac2sMj7K 3aDyoKyA3gAdHFnSDTJcGkDIFg1SvlU0vZ82+BnZcbJfNKLvsqLZPE3f13qM+9Lv 7U/70FLSSqa0YjaISD8+5U2gU6eOEdfJ2Vjwa9DGvt7XYcPW/BNZwk8MeG9FEEBX dyCHMJ22YSk+fujWQjIyNJVK4JO/wfxf0OcS9Ph2M2xxF9mHo5fj0ONvS5XIB7cH HW8lHfD/HILzfOnF9sJTECs7s0U1e5Rosq+BkFQgla5YClbAX6PU6+4zwJOmmkQ4 aFMbshMZ2xoVoZU7G6+3p2ngjpmejMYSt3Av+YIo0XZBNnEkZ8msycRI0gztbWYS 1GE5FMWdc9zxHS6djh+3hyrL50Oq2IkuN5H+Mm0PmkSQ9Tw4jpF3z8LjFXcCl2iN 2cpKMJbggAr9XuDS+iKAfXtM3QkeIAhgRUzs6ILAejlfaN8G1ctcO03dQOaBgFEu EinN1UOCjwiie+NGoDDAWRg9rYFhN2BLt2A+P2gEaKPSflV6eGeyEvQWrFYBK5RS 73ftXbQ7k8Y9LQGylqhJ0DUnu9qnUiSdr8icesrLRrUV/XJwRgyKaDDooZh4x9c5 +nlK1sgcseC86jVZrbFxFSi4cPMPWItyuRND3rOgnlJFtW1CysBYeGJoqKSpVAmK FGNCUUPeGvivjGy9rBhnxYYfb+4tvR0q7jidIaZXfFhQj38ySX7uqK0efukwFILC lq2EgKWcsbkPRJyaPQaizOr9Cfaf/rWMQJgp2A+n+fNXGXR+Uv7IjRxuogOuY7Dq 8/gbOIzYEPkPcnyzIR6gyWg6hBf75k+pl7xAvCLPJL1PUwOCpUDxJHoIPpREyumL 2r4eBSy71bo9MHLNlvV2ITclo3uYL3l6SIwWoae+tP9Ilv99Vj30jgs9NVe1BfwC 3lU+FCkdhrt7wWMifl2RAHPstpGyD/AhSen++ndv/G0BpPOHf/nD48tNZ4FhLVAB 2G6oaOQCqfwxAFThPFy9B9rxJxJ96A5CE9dXQ0UkCrprhNvsTxLssk/S5qi6+sNU fi86J0U+lryqLFXcMyeeIifAMxrKhwvwdZObP4eeOgeON4zYxdyX00wu0ZG9uzrV CNjnZgUy9B2ZYI+2aXlQsPmz+KIYTMeedOVgLDRXn82G9UcZ21mORZhcjM8yIKoz VMrM/esXtqJ12jYJFLftUkCC0U5kICMuhy5YDkUBbOUv6dfn3VU7GRZiHnWKyZfj oCQ1e4wuZaFr3JdADvIAiiHaPXet6SadIIY3SEiRZoqBssorHl7qcbd4Prk/f1vL JNLy1+/Wmvy1BxVkPHqPe3+awRXgplmEpbm3fzNcuCPQ7KfeWpkl0mKjd95Ry0Cp mQvipkq7uuxlbz9GY7wSooCGHrGyEzsASjYWJO2s+I5xSv7/plq46jS/NwqUliSW hJhsGygcL65MsibjVaUmwi7DAJhN5sM0oVniZtvs6muV/wS+k/N9tg7l5Kq46J55 NlsyBXUv9SLgthi9q7RIHzuZSabSsZzHhWy9OoWIIdxyxgh287gzNtzRHeD/H2x/ zz2PWg+5k3MSINAwxYiJpcE84NI30DWIK5gxp+bb42a9A0+U81z6mPUjQsg6kn2m 69QlNbsTjSA0TG+RSCkzNPm+fxWhN2y38plLJDwgCtfgFM4u6aMzYR6cCKkvKslS 3HvHlBUDlBMao7VnjxBU+/GMsDGvHsd04XqdEqOLkfhZEoYKTYgxouejWfOYJtk7 n18U/kQs+1tp9EJ0usuUtV7CUdP8upWPRqiy6/SJYBwqEGTCXfrbnufiv1I0O1a9 rBURtudCqw/T5Bk0h8zG4H1UXmfCGSqAEYijK0e7rBqUxD+LLJynL6S6LDp0WHXk eL0Ym1ZSDDKtZF/tA8rIh76yVUhD3k6n3N7uC23V6bW9Jok8yviphtPY5H3Hg7OK LWxrkT9+LmZVlGk5i8hZjVa8Mbjhe3E6rUF9jw0K8PQVWgToF0nQ2ffz14FzeVsQ X3Z++VmdnWFnp0Gb9j35zDCTdpG1mxbQv7FPzUWhWK+8Ib3Oq2w5lmR82gzj4sUd IDTJipjyoy+SdqFl9NgxPDMI5kVGxtIV5AdtXmew+3PW0OeXd1+/zPbXZaMXZGeA 7KNhQNrd7d8jt10Kmcqozz9k6x5zidLos59twxn14cq3rQMcXcXix+niS4cehLeH ZNYYi26jPq7HAXVN7OITjzIzGnNNMaqBJReUq11+VJUKPREbUl7JVpfk4FkWJg== =+jqP -----END PGP MESSAGE----- ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Simplify AD integration? 2014-07-30 13:47 Simplify AD integration? Corinna Vinschen ` (3 preceding siblings ...) 2014-07-30 17:28 ` Eric Blake @ 2014-07-30 18:10 ` Eric Blake 2014-07-30 18:43 ` Corinna Vinschen 2014-07-30 19:37 ` Achim Gratz 2014-07-30 18:15 ` Andrew DeFaria ` (2 subsequent siblings) 7 siblings, 2 replies; 53+ messages in thread From: Eric Blake @ 2014-07-30 18:10 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 5117 bytes --] [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 [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 539 bytes --] ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Simplify AD integration? 2014-07-30 18:10 ` Eric Blake @ 2014-07-30 18:43 ` Corinna Vinschen 2014-07-31 7:13 ` Achim Gratz 2014-08-04 19:00 ` Corinna Vinschen 2014-07-30 19:37 ` Achim Gratz 1 sibling, 2 replies; 53+ messages in thread From: Corinna Vinschen @ 2014-07-30 18:43 UTC (permalink / raw) To: cygwin [-- 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 --] ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Simplify AD integration? 2014-07-30 18:43 ` Corinna Vinschen @ 2014-07-31 7:13 ` Achim Gratz 2014-08-01 9:23 ` Corinna Vinschen 2014-08-04 19:00 ` Corinna Vinschen 1 sibling, 1 reply; 53+ messages in thread From: Achim Gratz @ 2014-07-31 7:13 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Simplify AD integration? 2014-07-31 7:13 ` Achim Gratz @ 2014-08-01 9:23 ` Corinna Vinschen 2014-08-01 17:43 ` Achim Gratz 0 siblings, 1 reply; 53+ messages in thread From: Corinna Vinschen @ 2014-08-01 9:23 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1398 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Simplify AD integration? 2014-08-01 9:23 ` Corinna Vinschen @ 2014-08-01 17:43 ` Achim Gratz 2014-08-01 18:22 ` Corinna Vinschen 0 siblings, 1 reply; 53+ messages in thread From: Achim Gratz @ 2014-08-01 17:43 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Simplify AD integration? 2014-08-01 17:43 ` Achim Gratz @ 2014-08-01 18:22 ` Corinna Vinschen 2014-08-01 18:25 ` Achim Gratz 0 siblings, 1 reply; 53+ messages in thread From: Corinna Vinschen @ 2014-08-01 18:22 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1192 bytes --] 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.139&view=markup#l622 -- 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 --] ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Simplify AD integration? 2014-08-01 18:22 ` Corinna Vinschen @ 2014-08-01 18:25 ` Achim Gratz 2014-08-01 18:43 ` Corinna Vinschen 0 siblings, 1 reply; 53+ messages in thread From: Achim Gratz @ 2014-08-01 18:25 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Simplify AD integration? 2014-08-01 18:25 ` Achim Gratz @ 2014-08-01 18:43 ` Corinna Vinschen 0 siblings, 0 replies; 53+ messages in thread From: Corinna Vinschen @ 2014-08-01 18:43 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1012 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Simplify AD integration? 2014-07-30 18:43 ` Corinna Vinschen 2014-07-31 7:13 ` Achim Gratz @ 2014-08-04 19:00 ` Corinna Vinschen 2014-08-06 8:48 ` Corinna Vinschen 1 sibling, 1 reply; 53+ messages in thread From: Corinna Vinschen @ 2014-08-04 19:00 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 2172 bytes --] 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, hmmmmm, *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 [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Simplify AD integration? 2014-08-04 19:00 ` Corinna Vinschen @ 2014-08-06 8:48 ` Corinna Vinschen 2014-09-01 11:42 ` Corinna Vinschen 0 siblings, 1 reply; 53+ messages in thread From: Corinna Vinschen @ 2014-08-06 8:48 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1442 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Simplify AD integration? 2014-08-06 8:48 ` Corinna Vinschen @ 2014-09-01 11:42 ` Corinna Vinschen 0 siblings, 0 replies; 53+ messages in thread From: Corinna Vinschen @ 2014-09-01 11:42 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1868 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Simplify AD integration? 2014-07-30 18:10 ` Eric Blake 2014-07-30 18:43 ` Corinna Vinschen @ 2014-07-30 19:37 ` Achim Gratz 1 sibling, 0 replies; 53+ messages in thread From: Achim Gratz @ 2014-07-30 19:37 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Simplify AD integration? 2014-07-30 13:47 Simplify AD integration? Corinna Vinschen ` (4 preceding siblings ...) 2014-07-30 18:10 ` Eric Blake @ 2014-07-30 18:15 ` Andrew DeFaria 2014-07-30 18:40 ` Corinna Vinschen 2014-07-31 13:22 ` D. Boland 2014-07-31 21:06 ` AW: " Christoph H. Hochstaetter 7 siblings, 1 reply; 53+ messages in thread From: Andrew DeFaria @ 2014-07-30 18:15 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Simplify AD integration? 2014-07-30 18:15 ` Andrew DeFaria @ 2014-07-30 18:40 ` Corinna Vinschen 2014-07-30 18:44 ` Corinna Vinschen ` (2 more replies) 0 siblings, 3 replies; 53+ messages in thread From: Corinna Vinschen @ 2014-07-30 18:40 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1999 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Simplify AD integration? 2014-07-30 18:40 ` Corinna Vinschen @ 2014-07-30 18:44 ` Corinna Vinschen 2014-07-30 19:09 ` Eric Blake 2014-07-30 20:04 ` Andrew DeFaria 2 siblings, 0 replies; 53+ messages in thread From: Corinna Vinschen @ 2014-07-30 18:44 UTC (permalink / raw) To: cygwin [-- Attachment #1.1: Type: text/plain, Size: 1030 bytes --] 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 [-- Attachment #1.2: pwdgrp-doc --] [-- Type: text/plain, Size: 32441 bytes --] ======= 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 mapping first. Here's how it works. - Well-known SIDs in the NT_AUTHORITY domain of the S-1-5-RID type, or aliases of the S-1-5-32-RID type are mapped to the uid/gid value RID[4]. For an overview of well-known SIDs, see [5]. Examples: "SYSTEM" S-1-5-18 <=> uid/gid: 18 "Users" S-1-5-32-545 <=> uid/gid: 545 - Other well-known SIDs in the NT_AUTHORITY domain (S-1-5-X-RID): S-1-5-X-RID <=> uid/gid: 0x1000 * X + RID Example: "NTLM Authentication" S-1-5-64-10 <=> uid/gid: 0x4000A == 262154 - Other well-known SIDs: S-1-X-Y <=> uid/gid: 0x10000 + 0x100 * X + Y Example: "LOCAL" S-1-2-0 <=> uid/gid: 0x10200 == 66048 "Creator Group" S-1-3-1 <=> uid/gid: 0x10301 == 66305 - Logon SIDs: The own LogonSid is converted to the fixed uid 0xfff == 4095 and named "CurrentSession". Any other LogonSid is converted to the fixed uid 0xffe == 4094 and named "OtherSession". - Mandatory Labels: S-1-16-RID <=> uid/gid: 0x60000 + RID Example: "Medium Mandatory Level" S-1-16-8192 <=> uid/gid: 0x62000 == 401408 - Accounts from the local machine's user DB (SAM): S-1-5-21-X-Y-Z-RID <=> 0x30000 + RID Example: "Administrator" S-1-5-21-X-Y-Z-500 <=> uid/gid: 0x301f4 == 197108 - Accounts from the machine's primary domain: S-1-5-21-X-Y-Z-RID <=> 0x100000 + RID Example: "Domain Users" S-1-5-21-X-Y-Z-513 <=> 0x100201 == 1049089 - Accounts from a trusted domain of the machine's primary domain: S-1-5-21-X-Y-Z-RID <=> trustPosixOffset(domain) + RID "trustPosixOffset"? This needs a bit of explanation. This value exists in Windows domains already since before Active Directory days. What happens is this. If you create a domain trust between two domains, a trustedDomain entry will be added to both databases. It describes how *this* domain trusts the *other* domain. One attribute of a trust is a 32 bit value called "trustPosixOffset" For each new trust, trustPosixOffset will get some automatic value. In recent AD domain implementations, the first trusted domain will get trustPosixOffset set to 0x80000000. Following domains will get lower values. Unfortunately the domain admins are allowed to set the trustPosixOffset value for each trusted domain to some arbitrary 32 bit value, no matter what the other trustPosixOffsets are seet to, thus allowing any kind of collisions between the trustPosixOffsets of domains. That's not exactly helpful, but as the user of this value, we have to *trust* the domain admins to set trustPosixOffset to sensible values, or to keep it at the system chosen values. So, for the first (or only) trusted domain of your domain, the automatic offset is 0x80000000. An example for a user of that trusted domain is: S-1-5-21-X-Y-Z-1234 <=> uid/gid 0x800004d2 == 2147484882 There's one problem with this approach. Assuming you're running in the context of a local SAM user on a domain member machine. Local users don't have the right to fetch this kind of domain information from the DC, they'll get permission denied. In this case Cygwin will fake a sensible trustPosixOffset value. Another problem is if the AD administrators chose an unreasonable small POSIX offset value. Anything below the hexadecimal value 0x100000 (the POSIX offset of the primary domain) is bound to produce collisions with system accounts as well as local accounts. The right thing to do in this case is to notify your administrator of the problem and to ask for moving the offset to a more reasonable value. However, to reduce the probability for collisions, Cygwin overrides this offset with a sensible fixed replacement offset. - Local accounts from another machine in the network: There's no SID<=>uid/gid mapping implemented for this case. The problem is, there's no way to generate a bijective mapping. There's no central place which keeps an analogue value of the trustPosixOffset, and there's the additional problem that the LookupAccountSid and LookupAccountName functions cannnot resolve the SIDs, unless they know the name of the machine this SID comes from. And even then it will probably suffer a "Permission denied" when trying to ask the machine for its local account. SFU just prints the account RID in this case, Cygwin maps the account to the fake accounts "Unknown+User"/"Unknown+Group" with uid/gid -1. Now we have a semi-bijective mapping between SIDs and POSIX uid/gid values, but, given that we have potentially users and groups in different domains having the same name, how do we uniquely differ between them by name? Well, we can do that by making their names unique in a per-machine way. Dependent on the domain membership of the account, and dependent of the machine being a domain member or not, the user and group names will be generated using a domain prefix and a separator character between domain and account name. The default separator character is the plus sign, '+', as in SFU. - Well-known SIDs will have the separator character prepended: "+SYSTEM", "+LOCAL", "+Medium Mandatory Level", ... - If the machine is no domain member machine, only local accounts can be resolved into names, so for ease of use, just the account names are used as Cygwin user/group names: "corinna", "bigfoot", "None", ... - If the machine is a domain member machine, all accounts from the primary domain of the machine are mapped to Cygwin names without domain prefix: "corinna", "bigfoot", "Domain Users", ... while accounts from other domains are prepended by their domain: "DOMAIN1+corinna", "DOMAIN2+bigfoot", "DOMAIN3+Domain Users", ... - Local machine accounts of a domain member machine get a Cygwin user name the same way as accounts from another domain: The local machine name gets prepended: "MYMACHINE+corinna", "MYMACHINE+bigfoot", "MYMACHINE+None", ... - If LookupAccountSid fails, Cygwin checks the accounts against the known trusted domains. If the account is from one of the trusted domains, an artificial account name is created. It consists of the domain name, and a special name created from the account RID: "MY_DOM+User(1234)", "MY_DOM+Group(5678)" Otherwise we know nothing about this SID, so it will be mapped to the fake accounts "Unknown+User"/"Unknown+Group" with uid/gid -1. ======= Caching ======= The information fetched from file or the Windows account database is cached by the process. The cached information is inherited by child processes. While usually working fine, this has some drawbacks. Consider a shell calling `id'. `id' fetches all group information from the current token and caches them. Unfortunately `id' doesn't start any child processes, so the information is lost as soon as `id' exits. But there's another caching mechanism available. If cygserver is running it will provide passwd and group entry caching for all processes in a Cygwin process tree, which first process has been started after cygserver. So, if you start a Cygwin Terminal and cygserver is running at the time, mintty, the shell, and all child processes will use cygserver caching. If you start a Cygwin Terminal and cygserver is not running a the time, none of the processes started inside this terminal window will use cygserver caching. The advantage of cygserver caching is that it's system-wide and, as long as cygserver is running, unforgetful. Every Cygwin process on the system will have the cygserver cache at its service. Additionally, all information requested from cygserver once, will be cached inside the process itself and, again, propagated to child processes. ========================================== Cygwin user names, home dirs, login shells ========================================== Obviously, if you don't maintain passwd and group files, you need to have a way to maintain the other fields of a passwd entry as well. Three things come to mind: - You want to use a Cygwin username different from your Windows username. Note: This is only supported via /etc/passwd and /etc/group files. A Cygwin username maintained in the Windows user databases would require very costly (read: slow) seach operations. - You want a home dir different from the default /home/$USER. - You want to specify a different login shell than /bin/bash. How this is done depends on your account being a domain account or a local account. Let's start with the default. Assuming your Windows account name is "bigfoot" and your domain is "MY_DOM". Your default passwd entry in absence of anything I'll describe below looks like this: bigfoot:*:<uid>:<gid>:U-MY_DOM\bigfoot,S-1-5-....:/home/bigfoot:/bin/bash or, if your account is from a different domain than the primary domain of the machine: MY_DOM+bigfoot:*:<uid>:<gid>:U-MY_DOM\bigfoot,S-1-5-....:/home/bigfoot:/bin/bash Yes, the default homedir is still /home/bigfoot. If your account is a domain account: Either create an /etc/passwd and/or /etc/group file with entries for your account and use that, just as before. Or, Cygwin will utilize the posixAccount/posixGroup attributes per RFC 2307[6]. These attributes are by default available in Active Directory since Windows Server 2003 R2. They are "not set", unless utilized by the (deprecated since Server 2012 R2) Active Directory "Server for NIS" feature. The user attributes utilized by Cygwin are: unixHomeDirectory If set, will be used as Cygwin home directory. loginShell If set, will be used as Cygwin login shell. gecos Content will be added to the pw_gecos field. uidNumber See next section. The group attributes utilized by Cygwin are: gidNumber See next section. Apart from power shell scripting or inventing new CLI tools, these attributes can be changed using the "Attribute Editor" tab in the user properties dialog of the "Active Directory Users and Computers" MMC snap-in. Alternatively, if the "Server for NIS" administration feature has been installed, there will be a "UNIX Attributes" tab which contains the required fields, except for the gecos field, which isn't really important anyway. Last resort is "ADSI Edit". The primary group of a user is always the Windows primary group set in Active Directory and can't be changed. If your machine is not a domain member machine or your account is a local account for some reason: Either create an /etc/passwd and/or /etc/group file with entries for your account and use that, just as before. Or enter the information into the "Comment" field of your local user entry. In the "Local Users and Groups" MMC snap-in it's called "Description". You can utilze this field even if you're running a "home edition" of Windows, using the command line. The "net user" command allows to set all values in the SAM, even if the GUI is crippled. A Cygwin SAM comment entry looks like this: <cygwin key="value" key="value" [...] /> The supported keys are home="value" Sets the Cygwin home dir to value. shell="value" Sets the Cygwin login shell to value. group="value" Sets the Cygwin primary group of the account to value, provided that the user *is* already a member of that group. This allows to override the default "None" primary group for local accounts. One nice idea here is, for instance group="Users". unix="value" Sets the NFS/Samba uid of the user to the decimal value. See the next chapter. The <cygwin .../> string can start at any point in the comment, but you have to follow the rules: - It starts with "<cygwin " and ends with "/>". - The "cygwin" string and the key names have to be lowercase. - No spaces between key and "value", just the equal sign. - The value must be placed within double quotes and it must not contain a double quote itself. The double quotes are required for the decimal values as well! CMD example: net user corinna /comment:"<cygwin home=\"/home/foo\"/>" Bash example (use single quotes): net user corinna /comment:'<cygwin home="/home/foo"/>' For changing group comments, use the `net localgroup' command. The supported key/value pair for groups are unix="value" Sets the NFS/Samba gid of the group to the decimal value. See the next chapter. =================== NFS account mapping =================== Microsoft's NFS client does not map the uid/gid values on the NFS shares to SIDs. There's no such thing as a (fake) security descriptor returned to the application. Rather, via an undocumented API an applications can fetch RFC 1813 compatible NFSv3 stat information from the share[7]. This is what Cygwin is using to show stat information for files on NFS shares. The problem is, while all other information in this stat record, like timestamps, file size etc., can be used by Cygwin, Cygwin had no way to map the values of the st_uid and st_gid members to a Windows SID for a long time. So it just faked the file owner info and claimed that it's you. However, SFU has, over time, developed multiple methods to map UNIX uid/gid values on NFS shares to Windows SIDs. You'll find the full documentation of the mapping methods in [8]. Cygwin now utilizes the RFC 2307 mapping for this purpose. This is most of the time provided by an AD domain, but it could also be a standalone LDAP mapping server. Per RFC 2307, the uid is in the attribute uidNumber. For groups, the gid is in the gidNumber attribute. When Cygwin stat's files on an NFS share, it asks the mapping server via LDAP in two different ways, depending on the role of the mapping server. - If the server is an AD domain controller, it asks for an account with uidNumber attribute == st_uid field of the stat record returned by NFS. If an account matches, AD returns the Windows SID, so we have an immediate mapping from UNIX uid to a Windows SID, if the user account has a valid uidNumber attribute. For groups, the method is the same, just that Cygwin asks for a group with gidNumber attribute == st_gid field of the stat record. - If the server is a standalone LDAP mapping server Cygwin asks for the same uidNumber/gidNumber attributes, but it can't expect that the LDAP server knows anything about Windows SIDs. Rather, the mapping server returns the account name. Cygwin then asks the DC for an account with this name, and if that succeeds, we have a mapping between UNIX uid/gid and Windows SIDs. The mapping will be cached for the lifetime of the process, and inherited by child processes. ===================== Samba account mapping ===================== A fully set up Samba with domain integration is running winbindd to map Window SIDs to artificially created UNIX uids and gids, and this mapping is transparent within the domain, so Cygwin doesn't have to do anything special. However, setting up winbindd isn't for everybody, and it fails to map Windows accounts to already existing UNIX users or groups. In contrast to NFS, Samba returns security descriptors, but unmapped UNIX accounts get special SIDs: - A UNIX user account with uid X is mapped to the Windows SID S-1-22-1-X. - A UNIX group account with gid X is mapped to SID S-1-22-2-X. As you can see, even though we have SIDs, they just reflect the actual uid/gid values on the UNIX box in the RID value. It's only marginally different from the NFS method, so why not just use the same method as for NFS? That's what Cygwin will do. If it encounters a S-1-22-x-y SID, it will perform the same RFC 2307 mapping as for NFS shares. For home users without any Windows domain or LDAP server per RFC 2307, but with a Linux machine running Samba, just add this information to your SAM account. Assuming the uid of your Linux user account is 505 and the gid of your primary group is, say, 100, just add the values to your SAM user and group accounts. The following example assumes you didn't already add something else to the comment field. To your user's SAM comment (remember: called "Description" in the GUI), add: <cygwin group="Users" unix="505"/> To the user's group SAM comment add: <cygwin unix="100"/> This should be sufficient to work on your Samba share and to see all files owned by your Linux user account as your files. =========================== The /etc/nsswitch.conf file =========================== Last, but not least, let's talk about the way to configure how the mapping works on your machine. On Linux and some other UNIXy OSes, we have a file called /etc/nsswitch.conf[9]. One part of it is to specify how the passwd and group entries are generated. That's what Cygwin now provides as well. The /etc/nsswitch.conf file is optional. If you don't have one, Cygwin uses sensible defaults. Note: The /etc/nsswitch.conf file is read exactly once by the first process of a Cygwin process tree. If there was no /etc/nsswitch.conf file when this first process started, then no other process in the running Cygwin process trees will try to read the file. If you create or change /etc/nsswitch.conf, you need to restart all Cygwin processes that need to see the change. If the process you want to see the change is a child of another process, you need to restart all of that process's parents, too. For example, if you run Vim inside the default Cygwin Terminal, Vim is a child of your shell, which is a child of mintty.exe. If you edit /etc/nsswitch.conf in that Vim instance, your shell won't immediately see the change, nor will Vim if you restart it from that same shell instance. This is because both are getting their nsswitch information from their ancestor, mintty.exe. You need to start a fresh terminal window for the change to take effect. By contrast, if you leave that Cygwin Terminal window open after making the change to /etc/nsswitch.conf, then restart a Cygwin service like cron, cron will see the change, because it is not a child of mintty.exe or any other Cygwin process. (Technically, it is a child of cygrunsrv, but that instance also restarts when you restart the service.) The reason we point all this out is that the requirements for restarting things are not quite as stringent as when you replace cygwin1.dll. If you have three process trees, you have three independent copies of the nsswitch information. If you start a fresh process tree, it will see the changes. As long as any process in an existing process tree remains running, all processes in that tree will continue to use the old information. So, what mischief can we perform with /etc/nsswitch.conf? To explain, lets have a look into an /etc/nsswitch.conf file set up to all default values: # /etc/nsswitch.conf passwd: files db group: files db db_prefix: auto db_separator: + db_enum: cache builtin The first line, starting with a hash '#' is a comment. The hash character starts a comment, just as in shell scripts. Everything up to the end of the line is ignored. So this: foo: bar # baz means, for the entry "foo", do "bar", ignore everything after the hash sign. "baz" is only a comment. The other lines define the available settings. The first word up to a colon is a keyword. Note that the colon *must* follow immediately after the keyword. This is a valid line: foo: bar This is not valid: foo : bar Apart from this restriction, the reminder of the line can have as many spaces and TABs as you like. This is a valid line: foo: bar baz Now let's have a look at the available keywords and settings. The two lines starting with the keywords "passwd" and "group" define where Cygwin gets its passwd and group information from. "files" means, fetch the information from the corresponding file in the /etc directory. "db" means, fetch the information from the Windows account databases, the SAM for local accounts, Active Directory for domain account. Examples: passwd: files Read passwd entries only from /etc/passwd. group: db Read group entries only from SAM/AD. group: files # db Read group entries only from /etc/group ("db" is ignored due to the preceding hash sign). passwd: files db Read passwd entries from /etc/passwd. If a user account isn't found, try to find it in SAM or AD. This is the default for both, passwd and group information. group: db files This is a valid entry, but the order will be ignored by Cygwin. If both, files and db are specified, Cygwin will always try the files first, then the db. The remaining entries define certain aspects of the Windows account database search. "db_prefix" determines how the Cygwin user or group name is created: db_prefix: auto This is the default. If your account is from the primary domain of your machine, or if your machine is a standalone machine (not a domain member), your Cygwin account name is just the Windows account name. If your account is from another domain, or if you're logged in as local user on a domain machine, the Cygwin username will be the combination of Windows domainname and username, with the separator char in between: MY_DOM+username (foreign domain) MACHINE+username (local account) Builtin accounts have just the separator char prepended: +LOCAL +Users Unknown accounts on NFS or Samba shares (that is, accounts which cannot be mapped to Windows user accounts via RFC 2307) get a Cygwin account name consisting of the artificial domains "Unix_User" or "Unix_Group" and the uid/gid value, for instance: Unix_User+0 (root) Unix_Group+10 (wheel) db_prefix: primary Like "auto", but primary domain accounts will be prepended by the domainname as well. db_prefix: always All accounts, even the builtin accounts, will have the domain name prepended: BUILTIN+Users "db_separator" defines the spearator char used to prepend the domain name to the user or group name. The default is '+': MY_DOM+username With "db_separator", you can define any ASCII char except space, tab, carriage return, line feed, and the colon, as separator char. Example: db_separator: \ MY_DOM\username "db_enum" defines the depth of a database search, if an application calls one of the enumeration functions getpwent[10] or getgrent[11]. The problem with these functions is, they neither allow to define how many entries will be enumerated when calling them in a loop, nor do they allow to add some filter criteria. They were designed back in the days, when only /etc/passwd and /etc/group files existed and the number of user accounts on a typical UNIX system was seldomly a three-digit number. These days, with user and group databases sometimes going in the six-digit range, they are a potential burden. For that reason, Cygwin does not enumerate all user or group accounts by default, but rather just a very small list, consisting only of the accounts cached in memory by the current process, as well as a handful of predefined builtin accounts. "db_enum" allows to specify the accounts to enumerate in a fine-grained way. It takes a list of sources as argument: db_enum: source1 source2 ... The recognized sources are the following: none No output from getpwent/getgrent at all. all The opposite. Enumerates accounts from all known sources, including all trusted domains. cache Enumerate all accounts currently cached in memory. builtin Enumerate the predefined builtin accounts for backward compatibility. These are five passwd accounts (SYSTEM, LocalService, NetworkService, Administrators, TrustedInstaller) and two group accounts (SYSTEM and TrustedInstaller). files Enumerate the accounts from /etc/passwd or /etc/group. local Enumerate all accounts from the local SAM. primary Enumerate all accounts from the primary domain. alltrusted Enumerate all accounts from all trusted domains. some.domain Enumerate all accounts from the trusted domain some.domain. The trusted domain can be given as Netbios flat name (MY_DOMAIN) or as dns domain name (my_domain.corp). In contrast to the aforementioned fixed source keywords, distinct domain names are caseinsensitive. Only domains which are actually trusted domains are enumerated. Unknown domains are simply ignored. Please note that getpwent/getgrent do *not* test if an account was already listed from another source, so an account can easily show up twice or three times. Such a test would be rather tricky, nor does the Linux implementation perform such test. Here are a few examples for /etc/nsswitch.conf: db_enum: none No output from getpwent/getgrent at all. The first call to the function immediately returns a NULL pointer. db_enum: cache files Enumerate all accounts cached by the current process, plus all entries from either the /etc/passwd or /etc/group file. db_enum: cache local primary Enumerate all accounts cached by the current process, all accounts from the SAM of the local machine, and all accounts from the primary domain of the machine. db_enum: local primary alltrusted Enumerate the accounts from the machine's SAM, from the primary domain of the machine, and from all trusted domains. db_enum: primary domain1.corp sub.domain.corp domain2.net Enumerate the accounts from the primary domain and from the domains domain1.corp, sub.domain.corp and domain2.net. db_enum: all Enumerate everything and the kitchen sink. ========== Footnotes: ========== [1] http://cygwin.com/cygwin-ug-net/ntsec.html [2] This may change. Right now the file is read in 32K chunks, but we could easily read the file in 64K chunks and, if we find the file is < 64K anyway, just cache the entire bunch, like before. Not implemented yet, but something to keep in mind. [3] http://msdn.microsoft.com/en-us/library/windows/desktop/aa379166%28v=vs.85%29.aspx http://msdn.microsoft.com/en-us/library/windows/desktop/aa379159%28v=vs.85%29.aspx [4] This is where Cygwin differs from SFU. The reason is that we need the old uid/gid values for backward compatibility. There are Cygwin packages (cron, for instance) who rely on the fact that the uid of SYSTEM is 18. In SFU, these accounts get mapped like the other built in SIDs. [5] http://support.microsoft.com/kb/243330 [6] https://tools.ietf.org/html/rfc2307 [7] https://tools.ietf.org/html/rfc1813 [8] http://blogs.technet.com/b/filecab/archive/2012/10/09/nfs-identity-mapping-in-windows-server-2012.aspx [9] http://linux.die.net/man/5/nsswitch.conf [10] http://linux.die.net/man/3/getpwent [11] http://linux.die.net/man/3/getgrent [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Simplify AD integration? 2014-07-30 18:40 ` Corinna Vinschen 2014-07-30 18:44 ` Corinna Vinschen @ 2014-07-30 19:09 ` Eric Blake 2014-07-30 19:23 ` Stephan Mueller 2014-07-30 19:29 ` Corinna Vinschen 2014-07-30 20:04 ` Andrew DeFaria 2 siblings, 2 replies; 53+ messages in thread From: Eric Blake @ 2014-07-30 19:09 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 745 bytes --] 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 [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 539 bytes --] ^ permalink raw reply [flat|nested] 53+ messages in thread
* RE: Simplify AD integration? 2014-07-30 19:09 ` Eric Blake @ 2014-07-30 19:23 ` Stephan Mueller 2014-07-30 19:32 ` Corinna Vinschen 2014-07-30 19:29 ` Corinna Vinschen 1 sibling, 1 reply; 53+ messages in thread From: Stephan Mueller @ 2014-07-30 19:23 UTC (permalink / raw) To: Eric Blake, cygwin 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Simplify AD integration? 2014-07-30 19:23 ` Stephan Mueller @ 2014-07-30 19:32 ` Corinna Vinschen 0 siblings, 0 replies; 53+ messages in thread From: Corinna Vinschen @ 2014-07-30 19:32 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 808 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Simplify AD integration? 2014-07-30 19:09 ` Eric Blake 2014-07-30 19:23 ` Stephan Mueller @ 2014-07-30 19:29 ` Corinna Vinschen 2014-07-30 19:43 ` Corinna Vinschen 1 sibling, 1 reply; 53+ messages in thread From: Corinna Vinschen @ 2014-07-30 19:29 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 2419 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Simplify AD integration? 2014-07-30 19:29 ` Corinna Vinschen @ 2014-07-30 19:43 ` Corinna Vinschen 0 siblings, 0 replies; 53+ messages in thread From: Corinna Vinschen @ 2014-07-30 19:43 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 2638 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Simplify AD integration? 2014-07-30 18:40 ` Corinna Vinschen 2014-07-30 18:44 ` Corinna Vinschen 2014-07-30 19:09 ` Eric Blake @ 2014-07-30 20:04 ` Andrew DeFaria 2014-07-30 20:49 ` Larry Hall (Cygwin) 2 siblings, 1 reply; 53+ messages in thread From: Andrew DeFaria @ 2014-07-30 20:04 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Simplify AD integration? 2014-07-30 20:04 ` Andrew DeFaria @ 2014-07-30 20:49 ` Larry Hall (Cygwin) 2014-07-30 21:19 ` Andrew DeFaria 0 siblings, 1 reply; 53+ messages in thread From: Larry Hall (Cygwin) @ 2014-07-30 20:49 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Simplify AD integration? 2014-07-30 20:49 ` Larry Hall (Cygwin) @ 2014-07-30 21:19 ` Andrew DeFaria 2014-07-30 22:20 ` Andrey Repin 2014-07-30 22:24 ` Larry Hall (Cygwin) 0 siblings, 2 replies; 53+ messages in thread From: Andrew DeFaria @ 2014-07-30 21:19 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Simplify AD integration? 2014-07-30 21:19 ` Andrew DeFaria @ 2014-07-30 22:20 ` Andrey Repin 2014-07-30 22:24 ` Larry Hall (Cygwin) 1 sibling, 0 replies; 53+ messages in thread From: Andrey Repin @ 2014-07-30 22:20 UTC (permalink / raw) To: Andrew DeFaria, cygwin 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 (anrdaemon@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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Simplify AD integration? 2014-07-30 21:19 ` Andrew DeFaria 2014-07-30 22:20 ` Andrey Repin @ 2014-07-30 22:24 ` Larry Hall (Cygwin) 2014-08-01 9:25 ` Corinna Vinschen 1 sibling, 1 reply; 53+ messages in thread From: Larry Hall (Cygwin) @ 2014-07-30 22:24 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Simplify AD integration? 2014-07-30 22:24 ` Larry Hall (Cygwin) @ 2014-08-01 9:25 ` Corinna Vinschen 2014-08-01 17:44 ` Achim Gratz 0 siblings, 1 reply; 53+ messages in thread From: Corinna Vinschen @ 2014-08-01 9:25 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 804 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Simplify AD integration? 2014-08-01 9:25 ` Corinna Vinschen @ 2014-08-01 17:44 ` Achim Gratz 2014-08-01 18:12 ` Corinna Vinschen 0 siblings, 1 reply; 53+ messages in thread From: Achim Gratz @ 2014-08-01 17:44 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Simplify AD integration? 2014-08-01 17:44 ` Achim Gratz @ 2014-08-01 18:12 ` Corinna Vinschen 2014-08-01 18:22 ` Achim Gratz 0 siblings, 1 reply; 53+ messages in thread From: Corinna Vinschen @ 2014-08-01 18:12 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 867 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Simplify AD integration? 2014-08-01 18:12 ` Corinna Vinschen @ 2014-08-01 18:22 ` Achim Gratz 2014-08-01 18:50 ` Corinna Vinschen 0 siblings, 1 reply; 53+ messages in thread From: Achim Gratz @ 2014-08-01 18:22 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Simplify AD integration? 2014-08-01 18:22 ` Achim Gratz @ 2014-08-01 18:50 ` Corinna Vinschen 2014-08-01 19:06 ` Achim Gratz 0 siblings, 1 reply; 53+ messages in thread From: Corinna Vinschen @ 2014-08-01 18:50 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 941 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Simplify AD integration? 2014-08-01 18:50 ` Corinna Vinschen @ 2014-08-01 19:06 ` Achim Gratz 0 siblings, 0 replies; 53+ messages in thread From: Achim Gratz @ 2014-08-01 19:06 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Simplify AD integration? 2014-07-30 13:47 Simplify AD integration? Corinna Vinschen ` (5 preceding siblings ...) 2014-07-30 18:15 ` Andrew DeFaria @ 2014-07-31 13:22 ` D. Boland 2014-07-31 14:17 ` Eric Blake 2014-07-31 21:06 ` AW: " Christoph H. Hochstaetter 7 siblings, 1 reply; 53+ messages in thread From: D. Boland @ 2014-07-31 13:22 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Simplify AD integration? 2014-07-31 13:22 ` D. Boland @ 2014-07-31 14:17 ` Eric Blake 2014-07-31 15:35 ` D. Boland 0 siblings, 1 reply; 53+ messages in thread From: Eric Blake @ 2014-07-31 14:17 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1029 bytes --] 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 [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 539 bytes --] ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Simplify AD integration? 2014-07-31 14:17 ` Eric Blake @ 2014-07-31 15:35 ` D. Boland 2014-07-31 22:20 ` Andrey Repin 2014-08-01 9:31 ` Corinna Vinschen 0 siblings, 2 replies; 53+ messages in thread From: D. Boland @ 2014-07-31 15:35 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Simplify AD integration? 2014-07-31 15:35 ` D. Boland @ 2014-07-31 22:20 ` Andrey Repin 2014-08-01 12:24 ` D. Boland 2014-08-01 9:31 ` Corinna Vinschen 1 sibling, 1 reply; 53+ messages in thread From: Andrey Repin @ 2014-07-31 22:20 UTC (permalink / raw) To: D. Boland, cygwin 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 (anrdaemon@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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Simplify AD integration? 2014-07-31 22:20 ` Andrey Repin @ 2014-08-01 12:24 ` D. Boland 2014-08-01 17:16 ` Andrew DeFaria 0 siblings, 1 reply; 53+ messages in thread From: D. Boland @ 2014-08-01 12:24 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Simplify AD integration? 2014-08-01 12:24 ` D. Boland @ 2014-08-01 17:16 ` Andrew DeFaria 2014-08-01 18:13 ` Corinna Vinschen 0 siblings, 1 reply; 53+ messages in thread From: Andrew DeFaria @ 2014-08-01 17:16 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Simplify AD integration? 2014-08-01 17:16 ` Andrew DeFaria @ 2014-08-01 18:13 ` Corinna Vinschen 0 siblings, 0 replies; 53+ messages in thread From: Corinna Vinschen @ 2014-08-01 18:13 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1184 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Simplify AD integration? 2014-07-31 15:35 ` D. Boland 2014-07-31 22:20 ` Andrey Repin @ 2014-08-01 9:31 ` Corinna Vinschen 1 sibling, 0 replies; 53+ messages in thread From: Corinna Vinschen @ 2014-08-01 9:31 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 2464 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 53+ messages in thread
* AW: Simplify AD integration? 2014-07-30 13:47 Simplify AD integration? Corinna Vinschen ` (6 preceding siblings ...) 2014-07-31 13:22 ` D. Boland @ 2014-07-31 21:06 ` Christoph H. Hochstaetter 2014-08-01 10:01 ` Corinna Vinschen 7 siblings, 1 reply; 53+ messages in thread From: Christoph H. Hochstaetter @ 2014-07-31 21:06 UTC (permalink / raw) To: cygwin 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" 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" ".\NetworkService" - cannot be used as a shortcut for "NT AUTHORITY\NetworkService" ".\WdiServiceHost" - cannot be used as a shortcut for "NT SERVICE\WdiServiceHost" Whenever ".\some name" cannot be used as shortcut for "some default\some name" in Win32, it should not be converted to "+some name" but to "DOMAIN+some name" in Cygwin. 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. >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. -Christoph -- 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Simplify AD integration? 2014-07-31 21:06 ` AW: " Christoph H. Hochstaetter @ 2014-08-01 10:01 ` Corinna Vinschen 2014-08-01 15:18 ` Larry Hall (Cygwin) 0 siblings, 1 reply; 53+ messages in thread From: Corinna Vinschen @ 2014-08-01 10:01 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 2846 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: Simplify AD integration? 2014-08-01 10:01 ` Corinna Vinschen @ 2014-08-01 15:18 ` Larry Hall (Cygwin) 0 siblings, 0 replies; 53+ messages in thread From: Larry Hall (Cygwin) @ 2014-08-01 15:18 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
end of thread, other threads:[~2014-09-01 11:42 UTC | newest] Thread overview: 53+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-07-30 13:47 Simplify AD integration? Corinna Vinschen 2014-07-30 14:38 ` Achim Gratz 2014-07-30 15:01 ` Corinna Vinschen 2014-07-30 16:33 ` Achim Gratz 2014-07-30 22:05 ` Andrey Repin 2014-07-30 15:29 ` Wolf Geldmacher 2014-07-30 15:43 ` Corinna Vinschen 2014-07-30 17:00 ` Eric Blake 2014-07-30 18:10 ` Eric Blake 2014-07-30 17:11 ` Larry Hall (Cygwin) 2014-07-30 17:28 ` Eric Blake 2014-07-30 18:10 ` Eric Blake 2014-07-30 18:43 ` Corinna Vinschen 2014-07-31 7:13 ` Achim Gratz 2014-08-01 9:23 ` Corinna Vinschen 2014-08-01 17:43 ` Achim Gratz 2014-08-01 18:22 ` Corinna Vinschen 2014-08-01 18:25 ` Achim Gratz 2014-08-01 18:43 ` Corinna Vinschen 2014-08-04 19:00 ` Corinna Vinschen 2014-08-06 8:48 ` Corinna Vinschen 2014-09-01 11:42 ` Corinna Vinschen 2014-07-30 19:37 ` Achim Gratz 2014-07-30 18:15 ` Andrew DeFaria 2014-07-30 18:40 ` Corinna Vinschen 2014-07-30 18:44 ` Corinna Vinschen 2014-07-30 19:09 ` Eric Blake 2014-07-30 19:23 ` Stephan Mueller 2014-07-30 19:32 ` Corinna Vinschen 2014-07-30 19:29 ` Corinna Vinschen 2014-07-30 19:43 ` Corinna Vinschen 2014-07-30 20:04 ` Andrew DeFaria 2014-07-30 20:49 ` Larry Hall (Cygwin) 2014-07-30 21:19 ` Andrew DeFaria 2014-07-30 22:20 ` Andrey Repin 2014-07-30 22:24 ` Larry Hall (Cygwin) 2014-08-01 9:25 ` Corinna Vinschen 2014-08-01 17:44 ` Achim Gratz 2014-08-01 18:12 ` Corinna Vinschen 2014-08-01 18:22 ` Achim Gratz 2014-08-01 18:50 ` Corinna Vinschen 2014-08-01 19:06 ` Achim Gratz 2014-07-31 13:22 ` D. Boland 2014-07-31 14:17 ` Eric Blake 2014-07-31 15:35 ` D. Boland 2014-07-31 22:20 ` Andrey Repin 2014-08-01 12:24 ` D. Boland 2014-08-01 17:16 ` Andrew DeFaria 2014-08-01 18:13 ` Corinna Vinschen 2014-08-01 9:31 ` Corinna Vinschen 2014-07-31 21:06 ` AW: " Christoph H. Hochstaetter 2014-08-01 10:01 ` Corinna Vinschen 2014-08-01 15:18 ` Larry Hall (Cygwin)
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).