Simplify AD integration?

Simplify AD integration?

[Corinna Vinschen]

[-- 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 --]

Re: Simplify AD integration?

[Achim Gratz]

Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> 1. Shall we remove the leading '+' from the builtin account names
>    or shall we keep it?

I'd rather keep it since it's a good reminder where that comes from.
 
> 2. Shall we stick to '+' as the separator char or choose another one?
>    If so, which one?

WJFFM at the moment, so I don't see a pressing need for variability.

> 3. Shall we keep the `db_prefix' variability or choose one of
>    the prefixing methods and stick to it?  If so, which one, auto,
>    primary, or always?

I'd rather keep this, although "auto" is all I use at the moment.  BTW,
would it be possible to recognize PRIMARYDOMAIN+user and (auto) user be
recognized as the same thing when auto is in effect?  The ability to
explicitly specify the prefix even though it isn't necessarily displayed
would most likely remove much of the potential need for variability in that
department (and defuse the booby trap in chown).

If you keep it, then there's an obvious candidate missing: "local+other",
which should prefix all accounts except the primary domain ones.  So it'd be
better to simply flag which groups to prefix, I'd think ("local", "primary",
"other") and specify this like symbolic modes in chmod, perhaps?

> Bonus question:
> 
> 4. Should Cygwin downcase all usernames when generating the Cygwin
>    username, so, if your Windows username is 'Ralph', your Cygwin
>    username will be 'ralph'?

I'd be in favor of this since I've already had two users that wouldn't see
their home directories until I figured out that they'd have their names
capitalized in AD...  as long as Windows is unable to distinguish users
based on the case there shouldn't be a problem.


Regards,
Achim.




--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Simplify AD integration?

[Corinna Vinschen]

[-- 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 --]

Re: Simplify AD integration?

[Wolf Geldmacher]

On 30.07.2014 15:47, Corinna Vinschen wrote:
> Hi folks,
>
>
> here's a set of question to those of you interested in the new
> passwd/group functionality.  This already has been discussed partially,
> but there was no conclusion.
>
> Right now, there's a lot of variability in the user names, based on the
> /etc/nsswitch.conf settings db_prefix and db_separator.
>
> The separator char is a '+' by default but can be replaced with other
> ASCII chars.  db_prefix allows three styles of user naming conventions:
>
>    Default is 'auto':
>
>      builtin accounts;   "+SYSTEM", "+LOCAL", etc.
>      primary domain      "corinna", "cgf", ...
>      other domain:       "DOMAIN1+walter", "DOMAIN2+mathilda"
>
>    If set to 'primary':
>
>      builtin accounts;   "+SYSTEM", "+LOCAL", etc.
>      primary domain      "MYDOMAIN+corinna", "MYDOMAIN+cgf", ...
>      other domain:       "DOMAIN1+walter", "DOMAIN2+mathilda"
>
>    If set to 'always':
>
>      builtin accounts;   "NT AUTHORITY+SYSTEM", "BULTIN+LOCAL", etc.
>      primary domain      "MYDOMAIN+corinna", "MYDOMAIN+cgf", ...
>      other domain:       "DOMAIN1+walter", "DOMAIN2+mathilda"
>
> "Primary domain" here is either the primary domain of the machine or the
> local SAM if the machine is no domain member.  "Other domain" here is
> either a trusted domain or the local SAM for domain machines.
>
> Together with the variable separator char this is an awful lot of
> variability, which has the potential side effect to complicate the
> code *and* debugging.
>
> Also, the leading '+' for builtin accounts results in some downsides,
> one of them for instance the fact that `chown +x' assumes that x is a
> numerical uid or gid.  Thus `chown +SYSTEM ...' fails.  On the other
> hand it simplifies the account handling inside of Cygwin.
>
> So I'd like to ask a few questions to which I'd like to have some brief
> answers, kind of like a poll, to get a better idea how we should
> proceed:
>
> 1. Shall we remove the leading '+' from the builtin account names
>     or shall we keep it?
>
> 2. Shall we stick to '+' as the separator char or choose another one?
>     If so, which one?
>
> 3. Shall we keep the `db_prefix' variability or choose one of
>     the prefixing methods and stick to it?  If so, which one, auto,
>     primary, or always?
>
> Bonus question:
>
> 4. Should Cygwin downcase all usernames when generating the Cygwin
>     username, so, if your Windows username is 'Ralph', your Cygwin
>     username will be 'ralph'?
>
>
> Thanks,
> Corinna
>
Just a thought:

Is there anything preventing you from using the pathname conventions for 
user names?

I seem to remember having seen constructs like "domain/user" (or ./user 
for the local domain) e.g. in Samba and found this to be quite 
intuitive, up to and including the ability to drop a leading "./" for 
local names.

It is also pretty close to how Windows specifies domain users names (but 
use the unixy '/' instead of the windozy '\' (or must I write '\\' ;-)) 
and positively avoids the chown gotcha.

Also some code could be reused for user name handling from path 
canonicalization?

Again - I'm not deep into this topic, so please feel free to ignore the 
suggestion if it doesn't make sense to you.

Cheers,
Wolf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Simplify AD integration?

[Corinna Vinschen]

[-- 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 --]

Re: Simplify AD integration?

[Achim Gratz]

Corinna Vinschen writes:
> I'm not sure if that would work as expected. Cygwin explicitely tests
> if the account name follows the current rule.  I'm not so sure what
> effects it would have, if getpwnam could return another username as
> the one given as parameter (apart from the case difference).

That could be a problem if an application checks for that, but then
there's only a handful of cases where you'd want to use an explicitly
prefixed user or group name.

> (and defuse the booby trap in chown).
>
> Well, hmm.  If we allow to specify "NT AUTHORITY+SYSTEM" or
> "BUILTIN+Administrators" even in "auto" or "primary" mode...
>
> Unfortunately this won't help in all cases.  I used a broken example :(
> The "LOCAL" account and a few others have NO domain.  Thus, they are
> simply +-prefixed ("+LOCAL"), even in 'db_prefix: always' mode.

We could invent one, for the sole reason to escape the leading "+".

> Tricky.

Certainly…

>> If you keep it, then there's an obvious candidate missing: "local+other",
>> which should prefix all accounts except the primary domain ones.
>
> Do you mean
>
>   builtin accounts;   "NT AUTHORITY+SYSTEM", "BUILTIN+Administrators", ...
>   primary domain      "corinna", "cgf", ...
>   other domain:       "DOMAIN1+walter", "DOMAIN2+mathilda"

Yes.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Simplify AD integration?

[Eric Blake]

[-- 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-----

Re: Simplify AD integration?

[Larry Hall (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

Re: Simplify AD integration?

[Eric Blake]

[-- 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-----

Re: Simplify AD integration?

[Eric Blake]

[-- 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 --]

Re: Simplify AD integration?

[Eric Blake]

[-- 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 --]

Re: Simplify AD integration?

[Andrew DeFaria]

On 7/30/2014 6:47 AM, Corinna Vinschen wrote:

I have not been actively watching this thread but if I'm correct we're 
adding NIS like capabilities to Cygwin so that /etc/passwd can easily be 
filled with say everybody in the domain? If so then bravo!

I also take it that it's not ready yet either. When it is, how would I 
install it?

> So I'd like to ask a few questions to which I'd like to have some brief
> answers, kind of like a poll, to get a better idea how we should
> proceed:
>
> 1. Shall we remove the leading '+' from the builtin account names
>     or shall we keep it?
>
> 2. Shall we stick to '+' as the separator char or choose another one?
>     If so, which one?

How about "@"?

> 3. Shall we keep the `db_prefix' variability or choose one of
>     the prefixing methods and stick to it?  If so, which one, auto,
>     primary, or always?
>
> Bonus question:
>
> 4. Should Cygwin downcase all usernames when generating the Cygwin
>     username, so, if your Windows username is 'Ralph', your Cygwin
>     username will be 'ralph'?

I say downshift them!
-- 
Andrew DeFaria
http://defaria.com


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Simplify AD integration?

[Corinna Vinschen]

[-- 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 --]

Re: Simplify AD integration?

[Corinna Vinschen]

[-- 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 --]

Re: Simplify AD integration?

[Corinna Vinschen]

[-- 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 --]

Re: Simplify AD integration?

[Eric Blake]

[-- 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 --]

RE: Simplify AD integration?

[Stephan Mueller]

Eric Blake writes:
" How bad would it be to treat the window's DOMAIN\user as cygwin
" user@DOMAIN?  Yes, it means string-splicing to rearrange strings when
" converting between the two forms, rather than just single-character
" replacement, but it might work.

Sounds reasonable to me.  Consider also that modern(*) Windows
recognizes (prefers?) user@domain as equivalent to domain\user in
places.  For example, when I log on, I can use either form in the user/
password dialog.

stephan();

(*) I use Windows 7 and 8

Re: Simplify AD integration?

[Corinna Vinschen]

[-- 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 --]

Re: Simplify AD integration?

[Corinna Vinschen]

[-- 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 --]

Re: Simplify AD integration?

[Achim Gratz]

Eric Blake writes:
>> 2. Shall we stick to '+' as the separator char or choose another one?
>>    If so, which one?
>
> Keeping + as mid-name separator is still best in my mind (Certainly
> better than ':', '\\', or '/', and there aren't many other characters
> besides ',' or '%' that would survive use through shell tilde-expansion
> while still being unlikely in the middle of a user name).  Mid-string is
> different than leading +.

The set of usable characters also includes '=' I suppose (plus '@' as
has been mentioned elsewhere in the thread).  They'd both work as
leading character for local accounts I'd think.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Simplify AD integration?

[Corinna Vinschen]

[-- 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 --]

Re: Simplify AD integration?

[Andrew DeFaria]

On 7/30/2014 11:40 AM, Corinna Vinschen wrote:
> On Jul 30 11:15, Andrew DeFaria wrote:
>> On 7/30/2014 6:47 AM, Corinna Vinschen wrote:
>
>> When it is, how would I
>> install it?
>
> The existing code is in almost all developer snapshots of the last few
> months.  Just try the last one from http://cygwin.com/snapshots/ and
> read my preliminary documentation attached to this mail again (and
> which, incidentally, is now in the offical docs in the repo as well).

I guess I was just curious as to what the package name might be... NIS? 
AD or ActiveDirectory or CygwinUserIntegration...

>> How about "@"?
>
> Dunno.  It *might* be a good alternative to '+'.  Personally I just
> dislike that a '@' is a less "light" character and it might give a wrong
> idea.  Email:  name AT domain.  Cygwin account:  domain AT name.

Yeah I wish we could switch it to name@domain...
-- 
Andrew DeFaria
http://defaria.com


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Simplify AD integration?

[Larry Hall (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

Re: Simplify AD integration?

[Andrew DeFaria]

On 7/30/2014 1:48 PM, Larry Hall (Cygwin) wrote:
> On 07/30/2014 04:04 PM, Andrew DeFaria wrote:
>> On 7/30/2014 11:40 AM, Corinna Vinschen wrote:
>>> On Jul 30 11:15, Andrew DeFaria wrote:
>>>> On 7/30/2014 6:47 AM, Corinna Vinschen wrote:
>>>
>>>> When it is, how would I
>>>> install it?
>>>
>>> The existing code is in almost all developer snapshots of the last few
>>> months.  Just try the last one from http://cygwin.com/snapshots/ and
>>> read my preliminary documentation attached to this mail again (and
>>> which, incidentally, is now in the offical docs in the repo as well).
>>
>> I guess I was just curious as to what the package name might be...
>> NIS? AD
>> or ActiveDirectory or CygwinUserIntegration...
>
> The implementation is part of the Cygwin DLL so it lives in the cygwin
> package.  That's why Corinna was directing you towards the Cygwin snapshots
> page.

Ah yes. That makes sense I guess. But does this mean that things will 
come in with the base package like /etc/nsswitch.conf, etc?
-- 
Andrew DeFaria
http://defaria.com


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Simplify AD integration?

[Andrey Repin]

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

Re: Simplify AD integration?

[Andrey Repin]

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

Re: Simplify AD integration?

[Larry Hall (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

Re: Simplify AD integration?

[Achim Gratz]

Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> Good points.  I might have overvalued the gain of easily recognizing
> builtin accounts by the leading '+' separator.

After some thinking with my eyes closed... not prefixing local accounts at
all would at least allow the sshd to see the local sshd user without jumping
through hoops, so that might be a net gain after all.  What I don't know:
what happens if a local and a primary domain user have the same name?


Regards,
Achim.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Simplify AD integration?

[D. Boland]

Corinna Vinschen wrote:
> So I'd like to ask a few questions to which I'd like to have some brief
> answers, kind of like a poll, to get a better idea how we should
> proceed:
> 
> 1. Shall we remove the leading '+' from the builtin account names
>    or shall we keep it?
> 
> 2. Shall we stick to '+' as the separator char or choose another one?
>    If so, which one?
> 
> 3. Shall we keep the `db_prefix' variability or choose one of
>    the prefixing methods and stick to it?  If so, which one, auto,
>    primary, or always?

I'm a legacy man. So I would say keep the MS symbol and use it like this \daniel,
\SYSTEM, etc.

> 
> Bonus question:
> 
> 4. Should Cygwin downcase all usernames when generating the Cygwin
>    username, so, if your Windows username is 'Ralph', your Cygwin
>    username will be 'ralph'?
> 

When in the Cywin domain, do like Cygwin. So, downcasing.

Cheers,
Daniel


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Simplify AD integration?

[Eric Blake]

[-- 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 --]

Re: Simplify AD integration?

[D. Boland]

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

AW: Simplify AD integration?

[Christoph H. Hochstaetter]

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

Re: Simplify AD integration?

[Andrey Repin]

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

Re: Simplify AD integration?

[Corinna Vinschen]

[-- 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 --]

Re: Simplify AD integration?

[Corinna Vinschen]

[-- 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 --]

Re: Simplify AD integration?

[Corinna Vinschen]

[-- 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 --]

Re: Simplify AD integration?

[Corinna Vinschen]

[-- 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 --]

Re: Simplify AD integration?

[D. Boland]

Andrey Repin wrote:
> 
> Greetings, D. Boland!
> 
> > I am not only a man of legacy, but also a very opinionated one. So give me some
> > slack when I say: the whole thing is insane. This would mean that from now on, I
> > have to use constructs like ~+daniel ~+SYSTEM in a Linux shell?? Bizarre.
> 
> No, you don't have. Default domain users are unprefixed, and the chance you
> would use internal accounts for something like shell access is exactly zero.
> 
> For the god's sake, read the thread before posting into it. Everything has
> been discussed no more than two days ago.

Yes, yes, I know. I wanted to react from the heart, without the intellectual baggage
of knowing the technical intricacies behind the problem.

D.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Simplify AD integration?

[Larry Hall (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

Re: Simplify AD integration?

[Andrew DeFaria]

On 8/1/2014 5:28 AM, D. Boland wrote:
> Andrey Repin wrote:
>>
>> Greetings, D. Boland!
>>
>>> I am not only a man of legacy, but also a very opinionated one. So give me some
>>> slack when I say: the whole thing is insane. This would mean that from now on, I
>>> have to use constructs like ~+daniel ~+SYSTEM in a Linux shell?? Bizarre.
>>
>> No, you don't have. Default domain users are unprefixed, and the chance you
>> would use internal accounts for something like shell access is exactly zero.
>>
>> For the god's sake, read the thread before posting into it. Everything has
>> been discussed no more than two days ago.
>
> Yes, yes, I know. I wanted to react from the heart, without the intellectual baggage
> of knowing the technical intricacies behind the problem.
>
> D.

Yes, who wants the facts to get in the way of a good emotion! ;-)
-- 
Andrew DeFaria
http://defaria.com


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Simplify AD integration?

[Achim Gratz]

Corinna Vinschen writes:
> - prefixed with the machine name if the machine is member of a domain.

That's exactly what I am having a bit of a problem with at the moment.
As discussed before, the user name "sshd" is hardcoded, which requires
to either make it a domain account (our AD admin has at least promised
to think about creating it, but of course "sshd" doesn't match any of
the naming rules they have for such accounts) or add it to /etc/passwd
with the prefix removed.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Simplify AD integration?

[Achim Gratz]

Corinna Vinschen writes:
> I'm not sure yet.  I guess I'll be going for a short /etc/nsswitch.conf
> file containing just the default values as comments and a pointer to the
> documentation.

Do you want this to reside in base-files?  We'd have to organize a
synchronized release to get rid of some of the stuff there that sets up
/etc/passwd and /etc/group anyway.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Simplify AD integration?

[Corinna Vinschen]

[-- 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 --]

Re: Simplify AD integration?

[Corinna Vinschen]

[-- 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 --]

Re: Simplify AD integration?

[Achim Gratz]

Corinna Vinschen writes:
> base-cygwin creates the /etc/passwd and /etc/group files (and the next
> version won't).  What is base-files doing to these files?

I misremembered, it currently only checks for "mkpasswd", "mkgroup" and
"group_GID_clash" and only warns about this and admonishes the user to
run:

 "mkpasswd -l [-d] > /etc/passwd"
 "mkgroup  -l [-d] > /etc/group"

It doesn't actually run those commands.  But both the warnings and the
possible remedies might have to be removed or adapted.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Simplify AD integration?

[Corinna Vinschen]

[-- 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 --]

Re: Simplify AD integration?

[Achim Gratz]

Corinna Vinschen writes:
> You don't have to care.  The next version of OpenSSH comes with
> Cygwin-specific code.  It will call
>
>   cygwin_internal(CW_CYGNAME_FROM_WINNAME, "sshd");
>
> to fetch the Cygwin username for the sshd account.  The OpenSSH patch
> has already been applied upstream, the CW_CYGNAME_FROM_WINNAME
> functionality is in Cygwin CVS(*), available for use by any service
> having a similar problem.

Great.  If you need a guinea pig for testing, I already have the latest
snapshot installed.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Simplify AD integration?

[Corinna Vinschen]

[-- 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 --]

Re: Simplify AD integration?

[Corinna Vinschen]

[-- 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 --]

Re: Simplify AD integration?

[Achim Gratz]

Corinna Vinschen writes:
> These fake accounts don't exist anymore.  Unknown SIDs (unlikely) will
> return an "Unknown User/Group" entry, or, if "db" is disabled in
> /etc/nsswitch.conf, getpwnam and friends will return NULL.

Good, then the whole section in /etc/profile can be removed.  But since
it doesn't get triggered anyway with the changes for AD integration in
place, there's alao no need to rush a release...


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Simplify AD integration?

[Corinna Vinschen]

[-- 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 --]

Re: Simplify AD integration?

[Corinna Vinschen]

[-- 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 --]

Re: Simplify AD integration?

[Corinna Vinschen]

[-- 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 --]