* More testing needed: New passwd/group AD/SAM integration
@ 2014-05-13 11:05 Corinna Vinschen
2014-05-13 12:19 ` Henry S. Thompson
0 siblings, 1 reply; 14+ messages in thread
From: Corinna Vinschen @ 2014-05-13 11:05 UTC (permalink / raw)
To: cygwin
[-- Attachment #1.1: Type: text/plain, Size: 3253 bytes --]
Hi list,
I'm still interested in testing of the new Cygwin code to have
user/group identification without requiring /etc/passwd and /etc/group
files.
This is a pretty big change, and it would be very helpful if as many
users as possible would be willing to give this a test.
Think about it: You'll never have to care for /etc/passwd and
/etc/group files again!
The latest preliminary documentation is attached to this mail again.
As usual the changes are present in the latest snapshots:
http://cygwin.com/snapshots/
The latest snapshots now handle "Microsoft Accounts", a marketing name
for a way to login with your email address(1). These accounts, if
local (non-domain) accounts, will have the "Users" group as their
primary group in Cygwin by default. The problems are outlined in
the thread "Problem with "None" Group on Non-Domain Members"(2).
==========
IMPORTANT:
==========
I'm still a bit unhappy with the account naming strategy and especially
the nsswitch.conf configuration. It would be more reliable if the user
names would be constructed in always the same way. So, here are the
things I'm still unsure about:
* db_separator in /etc/nsswitch.conf
Is it really such a good idea to have a configurable separator
char in user and group names? Is it important that it is
configurable? Isn't '+' a good choice for the separator and be
done with it?
* Right now the builtin accounts are prepended by the separator char:
+SYSTEM
+Users
...
This is how it's done in SFU, but... do we need that? The builtin
accounts are unambiguous. There's no way to create a user or group
with the same name asd a builtin account. And while compatibility
with SFU looks funny, it's not necessary.
So, shall we drop this prepending of the separator char and make
the builtin accounts "normal" accounts again, just like before?
SYSTEM
Users
...
* Right now there are three configurable strategies for the account
naming in /etc/nsswitch.conf:
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)
db_prefx: 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
Do we really need this flexibility?
Thanks,
Corinna
(1) ...and a nice way for MSFT to collect your personal information...
(2) http://cygwin.com/ml/cygwin/2014-05/threads.html#00059
--
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: 32247 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 user 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 user name. 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-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-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-X-Y-Z-1234 <=> uid/gid 0x800004d2 == 2147484882
There's only 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, mostly, sensible trustPosixOffset value for this session.
- 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 user name different from your Windows
user name.
- 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:
uid If set, will be used as Cygwin user name.
uidNumber See next section.
gecos Content will be added to the pw_gecos field.
unixHomeDirectory If set, will be used as Cygwin home directory.
loginShell If set, will be used as Cygwin login shell.
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
name="value" Sets the Cygwin user name to value.
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".
This is the *Windows* name of the group, not the
Cygwin name, assuming they differ.
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
name="value" Sets the Cygwin group name to value.
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
may 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_prefx: 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
As a special case, if the Cygwin account name differs from the
Windows account name, it will be prepended by the artificial domain
name "Posix_User" or "Posix_Group" if db_prefix is set to "always":
Posix_User+cygwin_user_name
Posix_Group+cygwin_group_name
"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://msdn.microsoft.com/en-us/library/cc980032.aspx
[9] http://linux.die.net/man/5/nsswitch.conf
[10] http://linux.die.net/man/3/getpwent
[11] http://linux.die.net/man/3/getgrent
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: More testing needed: New passwd/group AD/SAM integration
2014-05-13 11:05 More testing needed: New passwd/group AD/SAM integration Corinna Vinschen
@ 2014-05-13 12:19 ` Henry S. Thompson
2014-05-13 14:53 ` Corinna Vinschen
0 siblings, 1 reply; 14+ messages in thread
From: Henry S. Thompson @ 2014-05-13 12:19 UTC (permalink / raw)
To: cygwin
Corinna Vinschen writes:
> I'm still interested in testing of the new Cygwin code to have
> user/group identification without requiring /etc/passwd and /etc/group
> files.
So I installed the 2014-05-09 x86_64 snapshot, and did nothing else
(i.e. left /etc/{passwd,group} alone, didn't create an
/etc/nsswitch.conf), since your attachment didn't contain anything
which said "Minimum necessary to make this all work is ...".
I then successfully launched mintty, but (since the most important
aspect of my 'identity' is my ability to authenticate using Kerberos),
the next thing I tried did not work as expected:
> kinit
Password: ....
kinit: krb5_get_init_creds: unable to reach any KDC in realm [the right realm for me]
>
Switching back to 1.7.29-2 fixed the problem.
What can I do to help locate the problem (unless you have a Kerberos
principal around you presumably can't reproduce this for yourself)?
ht
--
Henry S. Thompson, School of Informatics, University of Edinburgh
10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
URL: http://www.ltg.ed.ac.uk/~ht/
[mail from me _always_ has a .sig like this -- mail without it is forged spam]
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: More testing needed: New passwd/group AD/SAM integration
2014-05-13 12:19 ` Henry S. Thompson
@ 2014-05-13 14:53 ` Corinna Vinschen
2014-05-13 16:30 ` Corinna Vinschen
0 siblings, 1 reply; 14+ messages in thread
From: Corinna Vinschen @ 2014-05-13 14:53 UTC (permalink / raw)
To: cygwin
[-- Attachment #1: Type: text/plain, Size: 1886 bytes --]
On May 13 12:57, Henry S. Thompson wrote:
> Corinna Vinschen writes:
>
> > I'm still interested in testing of the new Cygwin code to have
> > user/group identification without requiring /etc/passwd and /etc/group
> > files.
>
> So I installed the 2014-05-09 x86_64 snapshot, and did nothing else
> (i.e. left /etc/{passwd,group} alone, didn't create an
> /etc/nsswitch.conf), since your attachment didn't contain anything
> which said "Minimum necessary to make this all work is ...".
Yes, that was a mistake. I would be mostely interested in experiences
(and anoyances) by dropping /etc/passwd and /etc/group. The easiest
way to do that is NOT to move the files out of the way, but just
adding an /etc/nsswitch.conf file with this simple content:
passwd: db
group: db
And, having said that, I'd be really glad for more people reading and
ciriticising the preliminary documentation...
> I then successfully launched mintty, but (since the most important
> aspect of my 'identity' is my ability to authenticate using Kerberos),
> the next thing I tried did not work as expected:
>
> > kinit
> Password: ....
> kinit: krb5_get_init_creds: unable to reach any KDC in realm [the right realm for me]
> >
>
> Switching back to 1.7.29-2 fixed the problem.
>
> What can I do to help locate the problem (unless you have a Kerberos
> principal around you presumably can't reproduce this for yourself)?
I can reproduce it. This has nothing to with the account stuff, but
rather with a problem with the IPV6 definitions in the Mingw-w64 headers
I encountered lately, and which I had to workaround. Unfortunately
it has unwanted side-effects. Sigh. I'm looking into it.
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: More testing needed: New passwd/group AD/SAM integration
2014-05-13 14:53 ` Corinna Vinschen
@ 2014-05-13 16:30 ` Corinna Vinschen
2014-05-13 16:41 ` Henry S. Thompson
0 siblings, 1 reply; 14+ messages in thread
From: Corinna Vinschen @ 2014-05-13 16:30 UTC (permalink / raw)
To: cygwin
[-- Attachment #1: Type: text/plain, Size: 1346 bytes --]
On May 13 16:52, Corinna Vinschen wrote:
> On May 13 12:57, Henry S. Thompson wrote:
> > I then successfully launched mintty, but (since the most important
> > aspect of my 'identity' is my ability to authenticate using Kerberos),
> > the next thing I tried did not work as expected:
> >
> > > kinit
> > Password: ....
> > kinit: krb5_get_init_creds: unable to reach any KDC in realm [the right realm for me]
> > >
> >
> > Switching back to 1.7.29-2 fixed the problem.
> >
> > What can I do to help locate the problem (unless you have a Kerberos
> > principal around you presumably can't reproduce this for yourself)?
>
> I can reproduce it. This has nothing to with the account stuff, but
> rather with a problem with the IPV6 definitions in the Mingw-w64 headers
> I encountered lately, and which I had to workaround. Unfortunately
> it has unwanted side-effects. Sigh. I'm looking into it.
I just uploaded new snapshots to http://cygwin.com/snapshots/ which
are supposed to fix this issue. Kinit worked for me again with this.
I'd be grateful if you could check if it works for you too and, maybe,
test the account stuff a bit more...?
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: More testing needed: New passwd/group AD/SAM integration
2014-05-13 16:30 ` Corinna Vinschen
@ 2014-05-13 16:41 ` Henry S. Thompson
2014-05-13 16:44 ` Corinna Vinschen
0 siblings, 1 reply; 14+ messages in thread
From: Henry S. Thompson @ 2014-05-13 16:41 UTC (permalink / raw)
To: cygwin
Corinna Vinschen writes:
> On May 13 16:52, Corinna Vinschen wrote:
>> I can reproduce it. This has nothing to with the account stuff, but
>> rather with a problem with the IPV6 definitions in the Mingw-w64 headers
>> I encountered lately, and which I had to workaround. Unfortunately
>> it has unwanted side-effects. Sigh. I'm looking into it.
>
> I just uploaded new snapshots to http://cygwin.com/snapshots/ which
> are supposed to fix this issue. Kinit worked for me again with this.
> I'd be grateful if you could check if it works for you too and, maybe,
> test the account stuff a bit more...?
kinit works. ssh works. (New) screen works.
Both with /etc/passwd,group and no nsswitch.conf, and with
/etc/passwd,group,nsswitch.conf with passwd: db group: db
Any trivial way I can test that I am actually _getting_ identities
via the new route?
ht
--
Henry S. Thompson, School of Informatics, University of Edinburgh
10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
URL: http://www.ltg.ed.ac.uk/~ht/
[mail from me _always_ has a .sig like this -- mail without it is forged spam]
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: More testing needed: New passwd/group AD/SAM integration
2014-05-13 16:41 ` Henry S. Thompson
@ 2014-05-13 16:44 ` Corinna Vinschen
2014-05-13 18:00 ` Henry S. Thompson
0 siblings, 1 reply; 14+ messages in thread
From: Corinna Vinschen @ 2014-05-13 16:44 UTC (permalink / raw)
To: cygwin
[-- Attachment #1: Type: text/plain, Size: 1145 bytes --]
On May 13 17:29, Henry S. Thompson wrote:
> Corinna Vinschen writes:
>
> > On May 13 16:52, Corinna Vinschen wrote:
>
> >> I can reproduce it. This has nothing to with the account stuff, but
> >> rather with a problem with the IPV6 definitions in the Mingw-w64 headers
> >> I encountered lately, and which I had to workaround. Unfortunately
> >> it has unwanted side-effects. Sigh. I'm looking into it.
> >
> > I just uploaded new snapshots to http://cygwin.com/snapshots/ which
> > are supposed to fix this issue. Kinit worked for me again with this.
> > I'd be grateful if you could check if it works for you too and, maybe,
> > test the account stuff a bit more...?
>
> kinit works. ssh works. (New) screen works.
>
> Both with /etc/passwd,group and no nsswitch.conf, and with
> /etc/passwd,group,nsswitch.conf with passwd: db group: db
>
> Any trivial way I can test that I am actually _getting_ identities
> via the new route?
Call `id' :)
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: More testing needed: New passwd/group AD/SAM integration
2014-05-13 16:44 ` Corinna Vinschen
@ 2014-05-13 18:00 ` Henry S. Thompson
2014-05-13 19:20 ` Corinna Vinschen
0 siblings, 1 reply; 14+ messages in thread
From: Henry S. Thompson @ 2014-05-13 18:00 UTC (permalink / raw)
To: cygwin
Corinna Vinschen writes:
> On May 13 17:29, Henry S. Thompson wrote:
>> Any trivial way I can test that I am actually _getting_ identities
>> via the new route?
>
> Call `id' :)
OK, so that does yield. . .rather different results than it used to.
Poking around with id compared to the the contents of /etc/passwd
(from mkpasswd) and also compared to what my x86 install (not using
snapshot) does, I see one glitch and one difference:
Glitch (also true for x86 1.7.29-2):
id returns effectively immediately for all users and non-users _except_:
> time id Administrators
uid=544(+Administrators) gid=544(+Administrators)
groups=11(+Authenticated Users),544(+Administrators)
real 0m2.296s
user 0m0.015s
sys 0m0.015s
Difference:
[x86 1.7.29]> id TrustedInstaller
uid=4294967294(TrustedInstaller) gid=4294967294(TrustedInstaller)
groups=4294967294(TrustedInstaller)
[x86_64 snapshot]> id TrustedInstaller
id: TrustedInstaller: no such user
That's all I've found, happy to try other tests anyone can suggest.
ht
--
Henry S. Thompson, School of Informatics, University of Edinburgh
10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
URL: http://www.ltg.ed.ac.uk/~ht/
[mail from me _always_ has a .sig like this -- mail without it is forged spam]
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: More testing needed: New passwd/group AD/SAM integration
2014-05-13 18:00 ` Henry S. Thompson
@ 2014-05-13 19:20 ` Corinna Vinschen
2014-05-13 21:28 ` Henry S. Thompson
0 siblings, 1 reply; 14+ messages in thread
From: Corinna Vinschen @ 2014-05-13 19:20 UTC (permalink / raw)
To: cygwin
[-- Attachment #1: Type: text/plain, Size: 1444 bytes --]
On May 13 18:29, Henry S. Thompson wrote:
> Corinna Vinschen writes:
>
> > On May 13 17:29, Henry S. Thompson wrote:
> >> Any trivial way I can test that I am actually _getting_ identities
> >> via the new route?
> >
> > Call `id' :)
>
> OK, so that does yield. . .rather different results than it used to.
>
> Poking around with id compared to the the contents of /etc/passwd
> (from mkpasswd) and also compared to what my x86 install (not using
> snapshot) does, I see one glitch and one difference:
>
> Glitch (also true for x86 1.7.29-2):
> id returns effectively immediately for all users and non-users _except_:
> > time id Administrators
> uid=544(+Administrators) gid=544(+Administrators)
> groups=11(+Authenticated Users),544(+Administrators)
>
> real 0m2.296s
> user 0m0.015s
> sys 0m0.015s
This shouldn't happen as long as we still have the "+" prepended to
BUILTIN accounts(*). And, as a matter of fact, I can't reproduce this
with the latest from CVS (== the snapshot you're testing). Did you exit
your shell and restart it after creating the /etc/nsswitch.conf file as
described in my preliminary documentation?
Thanks,
Corinna
(*) I'd be grateful for input to the questions I asked in my OP, too.
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: More testing needed: New passwd/group AD/SAM integration
2014-05-13 19:20 ` Corinna Vinschen
@ 2014-05-13 21:28 ` Henry S. Thompson
2014-05-14 12:59 ` Corinna Vinschen
0 siblings, 1 reply; 14+ messages in thread
From: Henry S. Thompson @ 2014-05-13 21:28 UTC (permalink / raw)
To: cygwin
Corinna Vinschen writes:
> On May 13 18:29, Henry S. Thompson wrote:
>> Glitch (also true for x86 1.7.29-2):
>> id returns effectively immediately for all users and non-users _except_:
>> > time id Administrators
>> uid=544(+Administrators) gid=544(+Administrators)
>> groups=11(+Authenticated Users),544(+Administrators)
>>
>> real 0m2.296s
>> user 0m0.015s
>> sys 0m0.015s
>
> This shouldn't happen as long as we still have the "+" prepended to
> BUILTIN accounts(*). And, as a matter of fact, I can't reproduce this
> with the latest from CVS (== the snapshot you're testing). Did you exit
> your shell and restart it after creating the /etc/nsswitch.conf file as
> described in my preliminary documentation?
Yes, and I just re-did that, and I'm still getting the delay. You did
notice that it's the plural version (Administrator_s_) that has the
delay -- Administrator (no 's') is just as fast as all the others.
Adding the '+' doesn't change the behaviour.
Ah, it occured to me to do an strace, and I found the culprit, I
think:
19 392152 [main] id 16856 stat_worker: 0 = (\??\C:\C64\dev,0x1802C2940)
26 392178 [main] id 16856 fstat64: 0 = fstat(1, 0x23A4F0)
30 392208 [main] id 16856 isatty: 1 = isatty(1)
1085 393293 [main] id 16856 pwdgrp::fetch_account_from_windows: line: <+Administrators:*:544:544:,S-1-5-32-544:/:/sbin/nologin>
2253178 2646471 [main] id 16856 seterrno_from_win_error: /home/cygnus/vinschen/mknetrel/src/cygwin-snapshot-20140513-1/winsup/cygwin/sec_auth.cc:244 windows error 1355
187 2646658 [main] id 16856 geterrno_from_win_error: unknown windows
error 1355, setting errno to 13
Does that help?
> (*) I'd be grateful for input to the questions I asked in my OP, too.
Sorry, I am just a Un*x guy trying to live on a Windows box, I have
nothing like the necessary Windows sysadmin background to have an
opinion. I thought I would try your snapshots precisely _because_ I
understand almost nothing about all this -- I followed the 'mkpasswd'
instructions 8 years ago, and never touched things after that, and I
was just trying to help by seeing if there was anything a trial by a
naive user could uncover before things got fully released.
ht
--
Henry S. Thompson, School of Informatics, University of Edinburgh
10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
URL: http://www.ltg.ed.ac.uk/~ht/
[mail from me _always_ has a .sig like this -- mail without it is forged spam]
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: More testing needed: New passwd/group AD/SAM integration
2014-05-13 21:28 ` Henry S. Thompson
@ 2014-05-14 12:59 ` Corinna Vinschen
2014-05-14 14:58 ` Henry S. Thompson
0 siblings, 1 reply; 14+ messages in thread
From: Corinna Vinschen @ 2014-05-14 12:59 UTC (permalink / raw)
To: cygwin
[-- Attachment #1: Type: text/plain, Size: 4133 bytes --]
On May 13 22:15, Henry S. Thompson wrote:
> Corinna Vinschen writes:
> > On May 13 18:29, Henry S. Thompson wrote:
> >> Glitch (also true for x86 1.7.29-2):
> >> id returns effectively immediately for all users and non-users _except_:
> >> > time id Administrators
> >> uid=544(+Administrators) gid=544(+Administrators)
> >> groups=11(+Authenticated Users),544(+Administrators)
> >>
> >> real 0m2.296s
> >> user 0m0.015s
> >> sys 0m0.015s
> >
> > This shouldn't happen as long as we still have the "+" prepended to
> > BUILTIN accounts(*). And, as a matter of fact, I can't reproduce this
> > with the latest from CVS (== the snapshot you're testing). Did you exit
> > your shell and restart it after creating the /etc/nsswitch.conf file as
> > described in my preliminary documentation?
>
> Yes, and I just re-did that, and I'm still getting the delay. You did
> notice that it's the plural version (Administrator_s_) that has the
> delay -- Administrator (no 's') is just as fast as all the others.
Yes, I noticed the "s". But I missed to explain that I wasn't talking
about the delay. What I can't reproduce is that `id Administrators'
returns a result:
$ id +Administrators
uid=544(+Administrators) gid=544(+Administrators) groups=11(+Authenticated Users),544(+Administrators)
but:
$ id Administrators
id: Administrators: no such user
But now I understand why this occurs. It's the different handling of
account names without domain prefix on standalone vs. domain machines.
I applied a patch now which checks the incoming names for validity under
the current naming rules, so, in theory, `id Administrators' should now
return "no such user" for you as well.
> Adding the '+' doesn't change the behaviour.
>
> Ah, it occured to me to do an strace, and I found the culprit, I
> think:
>
> 19 392152 [main] id 16856 stat_worker: 0 = (\??\C:\C64\dev,0x1802C2940)
> 26 392178 [main] id 16856 fstat64: 0 = fstat(1, 0x23A4F0)
> 30 392208 [main] id 16856 isatty: 1 = isatty(1)
> 1085 393293 [main] id 16856 pwdgrp::fetch_account_from_windows: line: <+Administrators:*:544:544:,S-1-5-32-544:/:/sbin/nologin>
> 2253178 2646471 [main] id 16856 seterrno_from_win_error: /home/cygnus/vinschen/mknetrel/src/cygwin-snapshot-20140513-1/winsup/cygwin/sec_auth.cc:244 windows error 1355
> 187 2646658 [main] id 16856 geterrno_from_win_error: unknown windows
> error 1355, setting errno to 13
>
> Does that help?
Yes, thank you, it does. I tracked it down to the fact that in this
specific scenario, Cygwin asks for a domain controller of the "BUILTIN"
domain. This request for a domain controller name of a not really
existing domain takes about 2 secs. I added a check for the user's
SID to make sure the logon server name is only requested if the SID
is a "real" domain SID.
> > (*) I'd be grateful for input to the questions I asked in my OP, too.
>
> Sorry, I am just a Un*x guy trying to live on a Windows box, I have
> nothing like the necessary Windows sysadmin background to have an
> opinion. I thought I would try your snapshots precisely _because_ I
> understand almost nothing about all this -- I followed the 'mkpasswd'
> instructions 8 years ago, and never touched things after that, and I
> was just trying to help by seeing if there was anything a trial by a
> naive user could uncover before things got fully released.
That's ok. The debugging attempts in terms of your above `id' example
already lead me to understand why SFU decided to prefix the builtin
account names. This really makes sense to be able to check incoming
account names for validity. It's hard to explain, but I'm getting an
idea that we're better off in the long run to stick to the naming scheme
of SFU, or at least something close.
I just created new snapshots on http://cygwin.com/snapshots/
Please give'em a try.
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: More testing needed: New passwd/group AD/SAM integration
2014-05-14 12:59 ` Corinna Vinschen
@ 2014-05-14 14:58 ` Henry S. Thompson
2014-05-14 15:10 ` Corinna Vinschen
0 siblings, 1 reply; 14+ messages in thread
From: Henry S. Thompson @ 2014-05-14 14:58 UTC (permalink / raw)
To: cygwin
Corinna Vinschen writes:
> Yes, I noticed the "s". But I missed to explain that I wasn't talking
> about the delay. What I can't reproduce is that `id Administrators'
> returns a result:
>
> $ id +Administrators
> uid=544(+Administrators) gid=544(+Administrators) groups=11(+Authenticated Users),544(+Administrators)
>
> but:
>
> $ id Administrators
> id: Administrators: no such user
>
> But now I understand why this occurs. It's the different handling of
> account names without domain prefix on standalone vs. domain machines.
> I applied a patch now which checks the incoming names for validity under
> the current naming rules, so, in theory, `id Administrators' should now
> return "no such user" for you as well.
> I just created new snapshots on http://cygwin.com/snapshots/
> Please give'em a try.
Done, and now
[x86_64 20140514]> id Administrators
id: Administrators: no such user
[x86_64 20140514]> +Administrators
uid=544(+Administrators) gid=544(+Administrators) groups=11(+Authenticated Users),544(+Administrators)
with no delay in either case. So _that's_ sorted.
Overall, I now get the following clean pattern of id behaviour
wrt prefix '+':
w/o w
+ +
SYSTEM no yes
LocalService no yes
NetworkService no yes
Administrators no yes
TrustedInstaller no yes
Administrator yes no
cyg_server yes no
Guest yes no
ht yes no
postgres yes no
sshd yes no
[you can reproduce this using
> cut -d ':' -f 1 /etc/passwd | while read u; do echo -n "$u "; if id $u >/dev/null 2>/dev/null; then echo -n "yes "; else echo -n "no "; fi;if id '+'$u >/dev/null 2>/dev/null; then echo "yes"; else echo "no"; fi done
]
ht
--
Henry S. Thompson, School of Informatics, University of Edinburgh
10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
URL: http://www.ltg.ed.ac.uk/~ht/
[mail from me _always_ has a .sig like this -- mail without it is forged spam]
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: More testing needed: New passwd/group AD/SAM integration
2014-05-14 14:58 ` Henry S. Thompson
@ 2014-05-14 15:10 ` Corinna Vinschen
2014-05-16 22:08 ` Chris J. Breisch
0 siblings, 1 reply; 14+ messages in thread
From: Corinna Vinschen @ 2014-05-14 15:10 UTC (permalink / raw)
To: cygwin
[-- Attachment #1: Type: text/plain, Size: 2252 bytes --]
On May 14 15:15, Henry S. Thompson wrote:
> Corinna Vinschen writes:
>
> > Yes, I noticed the "s". But I missed to explain that I wasn't talking
> > about the delay. What I can't reproduce is that `id Administrators'
> > returns a result:
> >
> > $ id +Administrators
> > uid=544(+Administrators) gid=544(+Administrators) groups=11(+Authenticated Users),544(+Administrators)
> >
> > but:
> >
> > $ id Administrators
> > id: Administrators: no such user
> >
> > But now I understand why this occurs. It's the different handling of
> > account names without domain prefix on standalone vs. domain machines.
> > I applied a patch now which checks the incoming names for validity under
> > the current naming rules, so, in theory, `id Administrators' should now
> > return "no such user" for you as well.
>
> > I just created new snapshots on http://cygwin.com/snapshots/
> > Please give'em a try.
>
> Done, and now
>
> [x86_64 20140514]> id Administrators
> id: Administrators: no such user
> [x86_64 20140514]> +Administrators
> uid=544(+Administrators) gid=544(+Administrators) groups=11(+Authenticated Users),544(+Administrators)
>
> with no delay in either case. So _that's_ sorted.
>
> Overall, I now get the following clean pattern of id behaviour
> wrt prefix '+':
>
> w/o w
> + +
> SYSTEM no yes
> LocalService no yes
> NetworkService no yes
> Administrators no yes
> TrustedInstaller no yes
> Administrator yes no
> cyg_server yes no
> Guest yes no
> ht yes no
> postgres yes no
> sshd yes no
>
> [you can reproduce this using
> > cut -d ':' -f 1 /etc/passwd | while read u; do echo -n "$u "; if id $u >/dev/null 2>/dev/null; then echo -n "yes "; else echo -n "no "; fi;if id '+'$u >/dev/null 2>/dev/null; then echo "yes"; else echo "no"; fi done
> ]
Thanks for testing. If you find any other problems or annoyances,
please speak up.
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: More testing needed: New passwd/group AD/SAM integration
2014-05-14 15:10 ` Corinna Vinschen
@ 2014-05-16 22:08 ` Chris J. Breisch
2014-05-17 10:12 ` Corinna Vinschen
0 siblings, 1 reply; 14+ messages in thread
From: Chris J. Breisch @ 2014-05-16 22:08 UTC (permalink / raw)
To: cygwin
Corinna Vinschen wrote:
> Thanks for testing. If you find any other problems or annoyances,
> please speak up.
>
>
> Thanks,
> Corinna
>
I have a problem with ssh using this on a domain machine.
$ uname -a
CYGWIN_NT-6.3 cbreisch-win8 1.7.30s(0.272/5/3) 20140514 11:29:16 x86_64
Cygwin
I had ssh set up and working properly before installing the snapshot.
$ cat /etc/nsswitch.conf
passwd: files
group: files
If I leave it using files, I have no problems.
So, I change it to db and attempt to restart sshd
$ cat /etc/nsswitch.conf
passwd: db
group: db
# cygrunsrv -E sshd
# cygrunsrv -S sshd
cygrunsrv: Error starting a service: QueryServiceStatus: Win32 error 1062:
The service has not been started.
Add files back in:
$ cat /etc/nsswitch.conf
passwd: db files
group: db files
$ cygrunsrv -S sshd
works perfectly.
It appears to have something to do with the cyg_server account. Perhaps
because I set it up before I installed the snapshot? Why would that matter?
In any event, when set to use files, I can do this:
$ id cyg_server
uid=1008(cyg_server) gid=513(None) groups=513(None),0(root),545(Users)
when only using db, I get
$ id cyg_server
id: cyg_server: no such user
cyg_server does exist on the machine:
$ net users
User accounts for \\CBREISCH-WIN8
-------------------------------------------------------------------------------
Administrator Chris clfs
cyg_server Guest LocalAdmin
man sshd
The command completed successfully.
and is in /etc/passwd
$ grep cyg_server /etc/passwd
cyg_server:unused:1008:513:Privileged
server,U-CBREISCH-WIN8\cyg_server,S-1-5-21-2077790098-1200989767-2685255527-1008:/cygdrive/d/cygwin/root/var/empty:/bin/bash
Interesting, I just noticed that it says /cygdrive/d/cygwin/root...
There's no such path.
$ ls /cygdrive/d/cygwin/root
ls: cannot access /cygdrive/d/cygwin/root: No such file or directory
I changed my /cygdrive mount to /win
but even /win/d/cygwin/root doesn't exist. .../cygwin/root is from an
old install.
$ ls /win/d/cygwin/root
ls: cannot access /win/d/cygwin/root: No such file or directory
--
Chris J. Breisch
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: More testing needed: New passwd/group AD/SAM integration
2014-05-16 22:08 ` Chris J. Breisch
@ 2014-05-17 10:12 ` Corinna Vinschen
0 siblings, 0 replies; 14+ messages in thread
From: Corinna Vinschen @ 2014-05-17 10:12 UTC (permalink / raw)
To: cygwin
[-- Attachment #1.1: Type: text/plain, Size: 3708 bytes --]
On May 16 16:35, Chris J. Breisch wrote:
> Corinna Vinschen wrote:
> >Thanks for testing. If you find any other problems or annoyances,
> >please speak up.
> >
> >
> >Thanks,
> >Corinna
> >
>
> I have a problem with ssh using this on a domain machine.
>
> $ uname -a
> CYGWIN_NT-6.3 cbreisch-win8 1.7.30s(0.272/5/3) 20140514 11:29:16 x86_64
> Cygwin
>
> I had ssh set up and working properly before installing the snapshot.
>
> $ cat /etc/nsswitch.conf
> passwd: files
> group: files
>
> If I leave it using files, I have no problems.
>
> So, I change it to db and attempt to restart sshd
>
> $ cat /etc/nsswitch.conf
> passwd: db
> group: db
>
> # cygrunsrv -E sshd
> # cygrunsrv -S sshd
> cygrunsrv: Error starting a service: QueryServiceStatus: Win32 error 1062:
> The service has not been started.
I have it working here so I know it's not a generic problem. What
you're missing is a look into the system logs. Assuming you're not
running syslogd, you'll find the sshd log messages in the Windows Event
Viewer under "Windows Logs" -> "Application". In the logs, ignore the
entire text up to:
sshd: PID xxxx:
Only the above line is important.
Do you, by any chance, use privilege separation? If so, and if the
non-privileged account called "sshd" is a local account, you have a
problem. The local account is not in the primary domain, thus its
name is prepended with the machine name, in your case
CBREISCH-WIN8+sshd
There is no account called "sshd" anymore from the POV of Cygwin.
I have a patch in the loop to recitfy the problem. It requires two
changes, one of them to Cygwin, which I already checked in, and one of
them to the OpenSSH sources, which I sent upstream, but which hasn't
been applied nor commented upon yet.
For the time being, you have three choices to fix this problem in your
environment and keep the "db" setting:
- Change nsswitch.conf to the default
passwd: files db
group: file db
Remove all accounts from passwd, except the "sshd" account, so
the DBs are used for all accounts except "sshd".
- Alternatively, with "db"-only, remove the local account called "sshd"
and create a domain account in your primary domain called "sshd"
instead. This only works with "db_prefix: auto", the default setting,
otherwise the domain would be prepended to the Windows username.
- Alternatively, switch off privilege separation in /etc/sshd_config.
> Add files back in:
>
> $ cat /etc/nsswitch.conf
> passwd: db files
> group: db files
>
> $ cygrunsrv -S sshd
>
> works perfectly.
>
> It appears to have something to do with the cyg_server account. Perhaps
> because I set it up before I installed the snapshot? Why would that matter?
>
> In any event, when set to use files, I can do this:
>
> $ id cyg_server
> uid=1008(cyg_server) gid=513(None) groups=513(None),0(root),545(Users)
>
> when only using db, I get
>
> $ id cyg_server
> id: cyg_server: no such user
>
> cyg_server does exist on the machine:
>
> $ net users
>
> User accounts for \\CBREISCH-WIN8
Same as with the aforementioned "sshd" account. Try
$ getent passwd CBREISCH-WIN8+cyg_server
This account naming convention is documented in my preliminary
documentation which I attached to this email again. See the chapter
"How does it work?"
But the name of the account *running* sshd shouldn't be a problem.
If anything, it's probably the "sshd" account.
Hope that helps,
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: 31859 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-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-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-X-Y-Z-1234 <=> uid/gid 0x800004d2 == 2147484882
There's only 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, mostly, sensible trustPosixOffset value for this session.
- 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
may 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_prefx: 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://msdn.microsoft.com/en-us/library/cc980032.aspx
[9] http://linux.die.net/man/5/nsswitch.conf
[10] http://linux.die.net/man/3/getpwent
[11] http://linux.die.net/man/3/getgrent
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2014-05-17 10:00 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-05-13 11:05 More testing needed: New passwd/group AD/SAM integration Corinna Vinschen
2014-05-13 12:19 ` Henry S. Thompson
2014-05-13 14:53 ` Corinna Vinschen
2014-05-13 16:30 ` Corinna Vinschen
2014-05-13 16:41 ` Henry S. Thompson
2014-05-13 16:44 ` Corinna Vinschen
2014-05-13 18:00 ` Henry S. Thompson
2014-05-13 19:20 ` Corinna Vinschen
2014-05-13 21:28 ` Henry S. Thompson
2014-05-14 12:59 ` Corinna Vinschen
2014-05-14 14:58 ` Henry S. Thompson
2014-05-14 15:10 ` Corinna Vinschen
2014-05-16 22:08 ` Chris J. Breisch
2014-05-17 10:12 ` Corinna Vinschen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).