X-Recipient: archive-cygwin AT delorie DOT com DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:subject:message-id:reply-to :references:mime-version:content-type:in-reply-to; q=dns; s= default; b=q94dzppQDsQRA8fV+wbpzouM+wyiiggbJWjd7TZNk0T5/BkQzP8+V P00nt1lj8zC3QKqMr3Zz2HYYXLyZZ7NDy1b+JsPZXwGg4UQg9m1qMhQOCZAX/f4M 6D12n1miwnIKVBrBtqmE8xUQUzYUj/S7v+qUXCjg6lU+EjiWvJ/Ncs= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:subject:message-id:reply-to :references:mime-version:content-type:in-reply-to; s=default; bh=gUnWBBVI+/XHj6OPbAjQDvQLag8=; b=iLqp2W75UyNWzhLavP0rxroKNYSS vLFQF0iC6uLvkfTMpfvTcHkTGMiE/V6/7bJmXhfbQ/si3Se0gVnjplpHu3wzzS6M GzW/4D6YPK8hzZ/XJnT3X8/D9CbYaUPBEBYQnQhpMy/M+bQk8JcJSLi830yIpcpP /DezcudDAXj3xsE= Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_50,TBC autolearn=no version=3.3.2 X-HELO: calimero.vinschen.de Date: Fri, 16 May 2014 17:30:18 +0200 From: Corinna Vinschen To: cygwin AT cygwin DOT com Subject: Re: [ANNOUNCEMENT] New package: getent-2.18.90-2 Message-ID: <20140516153018.GI430@calimero.vinschen.de> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="R6sEYoIZpp9JErk7" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) --R6sEYoIZpp9JErk7 Content-Type: multipart/mixed; boundary="Oiv9uiLrevHtW1RS" Content-Disposition: inline --Oiv9uiLrevHtW1RS Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On May 16 15:31, Henry S. Thompson wrote: > Works for me with the 2015-05-14 x86_64 snapshot. >=20 > However, note that >=20 > > getent passwd > and > > getent group >=20 > output duplicate lines for some users/groups: >=20 > > getent group | wc > 18 31 731 > > getent group | sort -u | wc > 15 28 587 > > getent passwd | wc > 9 13 677 > > getent passwd | sort -u | wc > 6 9 437 >=20 > Bug or feature? Feature. Quote from my preliminary documentation (attached): 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. For the full description of the new, very configurable "db_enum" setting in /etc/nsswitch.conf, see the chapter called "The /etc/nsswitch.conf file" Corinna --=20 Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat --Oiv9uiLrevHtW1RS Content-Type: text/plain; charset=utf-8 Content-Disposition: attachment; filename=pwdgrp-doc Content-Transfer-Encoding: quoted-printable =3D=3D=3D=3D=3D=3D=3D History =3D=3D=3D=3D=3D=3D=3D 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. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D How does it work? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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<=3D>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 <=3D> uid/gid: 18 "Users" S-1-5-32-545 <=3D> uid/gid: 545 - Other well-known SIDs in the NT_AUTHORITY domain (S-1-5-X-RID): S-1-5-X-RID <=3D> uid/gid: 0x1000 * X + RID Example: "NTLM Authentication" S-1-5-64-10 <=3D> uid/gid: 0x4000A =3D=3D 262154 - Other well-known SIDs: S-1-X-Y <=3D> uid/gid: 0x10000 + 0x100 * X + Y Example: "LOCAL" S-1-2-0 <=3D> uid/gid: 0x10200 =3D=3D 66048 "Creator Group" S-1-3-1 <=3D> uid/gid: 0x10301 =3D=3D 66305 - Logon SIDs: The own LogonSid is converted to the fixed uid 0xfff =3D=3D 4095 and named "CurrentSession". Any other LogonSid is converted to the fixed uid 0xffe =3D=3D 4094 and named "OtherSession". - Mandatory Labels: S-1-16-RID <=3D> uid/gid: 0x60000 + RID Example: "Medium Mandatory Level" S-1-16-8192 <=3D> uid/gid: 0x62000 =3D=3D 401408 - Accounts from the local machine's user DB (SAM): S-1-5-21-X-Y-Z-RID <=3D> 0x30000 + RID Example: "Administrator" S-1-5-X-Y-Z-500 <=3D> uid/gid: 0x301f4 =3D=3D 197108 - Accounts from the machine's primary domain: =20=20 S-1-5-21-X-Y-Z-RID <=3D> 0x100000 + RID Example: "Domain Users" S-1-5-X-Y-Z-513 <=3D> 0x100201 =3D=3D 1049089 - Accounts from a trusted domain of the machine's primary domain: S-1-5-21-X-Y-Z-RID <=3D> 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 <=3D> uid/gid 0x800004d2 =3D=3D 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<=3D>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. =3D=3D=3D=3D=3D=3D=3D Caching =3D=3D=3D=3D=3D=3D=3D 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. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Cygwin user names, home dirs, login shells =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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. =20=20 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:*:::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:*:::U-MY_DOM\bigfoot,S-1-5-....:/home/bigfoot:/b= in/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: The supported keys are home=3D"value" Sets the Cygwin home dir to value. shell=3D"value" Sets the Cygwin login shell to value. group=3D"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=3D"Users". unix=3D"value" Sets the NFS/Samba uid of the user to the decimal value. See the next chapter. The string can start at any point in the comment, but you have to follow the rules: - It starts 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:"" Bash example (use single quotes): net user corinna /comment:'' For changing group comments, use the `net localgroup' command. The supported key/value pair for groups are unix=3D"value" Sets the NFS/Samba gid of the group to the decimal value. See the next chapter. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D NFS account mapping =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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 =3D=3D 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 =3D=3D 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. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Samba account mapping =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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: To the user's group SAM comment add: This should be sufficient to work on your Samba share and to see all files owned by your Linux user account as your files. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D The /etc/nsswitch.conf file =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D 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) =20=20=20=20 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. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Footnotes: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [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=3D= vs.85%29.aspx http://msdn.microsoft.com/en-us/library/windows/desktop/aa379159%28v=3D= 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 --Oiv9uiLrevHtW1RS-- --R6sEYoIZpp9JErk7 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJTdi8KAAoJEPU2Bp2uRE+gpysP/iiPq3MTSHfb0/nw4vZS5LUL IGLQLz0HlCJV3ctrJAkBQGgedEI+MxISBe3LnpS2VTw/xEgOAny2AIcmI7IT5DyE gi55qhnx9QzefFt+67wlU4ppF1SUM3tssBtpfrX7AyNc3oHGksFu4K2D57s878Sd t4zV1szL8sH8SvJQPgjG4QsmEUvx2HgigrUf3uqzV8tpH8C+oqnge9T3r0CJlWuP 2NV4cew/AWzc2VR3nBb7B6W6NoPFjIHzk9qyoQ+36js0FDoUJndZBMdftSGQEcJz XEig6X23gqM5iPiiiEjYhjODBxkBt4JS5Ojv+UB52JlmxUfQoJWtll1gS+PUscTJ BaU4fSJiJZFH7PDmRigN/VZQgSxtv4S5smaUPcn5f6t7PPukmrvNBABdH6suiJhJ HcDw7BoXMUJIK86Apg8HbIhrYA+9Wq7pyPZ4u55kXtEqF1HzHgF6yUC4CpldzWg4 1XhqOHd2RJMn/hg9qMgeExlx1+95vqEqBpW2MIPTgeZicbpwL+VpWjfbWl1uV8hj BhBRCYJAWSuqOK2F4LISRnCk0lHMtKoN968fNsJnu/CGqTwpc4ZKf1Xv0SVH7zIA yuJ95/6kLJF/rnxNKP4wRns6IbG1+se+2/f4VYCpquiyP2o/Yt81D4UhFpx6KYJa Jr4WrADOE9C+rDstB6OA =fCq+ -----END PGP SIGNATURE----- --R6sEYoIZpp9JErk7--