JehanneOS/newlib
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
451e1f4879
newlib/winsup/doc/ntsec.xml
Corinna Vinschen b4536f29c5 * ntsec.xml (ntsec-common): Drop outdated comment about underdeveloped 
Solaris ACL API support.
2014-08-31 20:06:14 +00:00

2047 lines
73 KiB
XML
Raw Blame History

<?xml version="1.0" encoding='UTF-8'?>
<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook V4.5//EN"
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd">
<sect1 id="ntsec"><title>POSIX accounts, permission, and security</title>
<para>This section discusses how the Windows security model is
utilized in Cygwin to implement POSIX account information, POSIX-like
permissions, and how the Windows authentication model is used to allow
cygwin applications to switch users in a POSIX-like fashion.</para>
<para>The setting of POSIX-like file and directory permissions is
controlled by the <link linkend="mount-table">mount</link> option
<literal>(no)acl</literal> which is set to <literal>acl</literal> by
default.</para>
<para>We start with a short overview. Note that this overview must
be necessarily short. If you want to learn more about the Windows security
model, see the <ulink url="http://msdn.microsoft.com/en-us/library/aa374860(VS.85).aspx">Access Control</ulink> article in MSDN documentation.</para>
<para>POSIX concepts and in particular the POSIX security model are not
discussed here, but assumed to be understood by the reader. If you
don't know the POSIX security model, search the web for beginner
documentation.</para>
<sect2 id="ntsec-common"><title>Brief overview of Windows security</title>
<para>In the Windows security model, almost any "object" is securable.
"Objects" are files, processes, threads, semaphores, etc.</para>
<para>Every object has a data structure attached, called a "security
descriptor" (SD). The SD contains all information necessary to control
who can access an object, and to determine what they are allowed to do
to or with it. The SD of an object consists of five parts:</para>
<itemizedlist spacing="compact">
<listitem><para>Flags which control several aspects of this SD. This is
not discussed here.</para></listitem>
<listitem><para>The SID of the object owner.</para></listitem>
<listitem><para>The SID of the object owner group.</para></listitem>
<listitem><para>A list of "Access Control Entries" (ACE), called the
"Discretionary Access Control List" (DACL).</para></listitem>
<listitem><para>Another list of ACEs, called the "Security Access Control List"
(SACL), which doesn't matter for our purpose. We ignore it here.</para></listitem>
</itemizedlist>
<para>Every ACE contains a so-called "Security IDentifier" (SID) and
other stuff which is explained a bit later. Let's talk about the SID first.
</para>
<para>A SID is a unique identifier for users, groups, computers and
Active Directory (AD) domains. SIDs are basically comparable to POSIX
user ids (UIDs) and group ids (GIDs), but are more complicated because
they are unique across multiple machines or domains. A SID is a
structure of multiple numerical values. There's a convenient convention
to type SIDs, as a string of numerical fields separated by hyphen
characters. Here's an example:</para>
<para>SID of a machine "foo":</para>
<screen>
S-1-5-21-165875785-1005667432-441284377
</screen>
<para>SID of a user "johndoe" of the system "foo":</para>
<screen>
S-1-5-21-165875785-1005667432-441284377-1023
</screen>
<para>The first field is always "S", which is just a notational convention
to show that this is a SID. The second field is the version number of
the SID structure, So far there exists only one version of SIDs, so this
field is always 1. The third and fourth fields represent the "authority"
which can be thought of as a type or category of SIDs. There are a
couple of builtin accounts and accounts with very special meaning which
have certain well known values in these third and fourth fields.
However, computer and domain SIDs always start with "S-1-5-21". The
next three fields, all 32 bit values, represent the unique 96 bit
identifier of the computer system. This is a hopefully unique value all
over the world, but in practice it's sufficient if the computer SIDs are
unique within a single Windows network.</para>
<para>As you can see in the above example, SIDs of users (and groups)
are identical to the computer SID, except for an additional part, the
so-called "relative identifier" (RID). So the SID of a user is always
uniquely attached to the system on which the account has been generated.</para>
<para>It's a bit different in domains. The domain has its own SID, and
that SID is identical to the SID of the first domain controller, on
which the domain is created. Domain user SIDs look exactly like the
computer user SIDs, the leading part is just the domain SID and the RID
is created when the user is created.</para>
<para>Ok, consider you created a new domain "bar" on some new domain
controller and you would like to create a domain account "johndoe":</para>
<para>SID of a domain "bar.local":</para>
<screen>
S-1-5-21-186985262-1144665072-740312968
</screen>
<para>SID of a user "johndoe" in the domain "bar.local":</para>
<screen>
S-1-5-21-186985262-1144665072-740312968-1207
</screen>
<para>So you now have two accounts called johndoe, one account
created on the machine "foo", one created in the domain "bar.local".
Both have different SIDs and not even the RID is the same. How do
the systems know it's the same account? After all, the name is
the same, right? The answer is, these accounts are <emphasis
role='bold'>not</emphasis> identical. All machines on the network will
treat these SIDs as identifying two separate accounts. One is
"FOO\johndoe", the other one is "BAR\johndoe" or "johndoe@bar.local".
Different SID, different account. Full stop. </para>
<para>Starting with Cygwin 1.7.33, Cygwin uses an automatic, internal
translation from Windows SID to POSIX UID/GID. This mechanism, which is
the preferred method for the SID&lt;=&gt;UID/GID mapping, is described in
detail in <xref linkend="ntsec-mapping"></xref>.</para>
<para>Prior to Cygwin 1.7.33, the last part of the SID, the so called
"Relative IDentifier" (RID), was by default used as UID and/or GID
when you created the <filename>/etc/passwd</filename> and
<filename>/etc/group</filename> files using the
<command><link linkend="mkpasswd">mkpasswd</link></command> and
<command><link linkend="mkgroup">mkgroup</link></command> tools.
These tools as well as reading accounts from <filename>/etc/passwd</filename>
and <filename>/etc/group</filename> files is still present in recent
versions of Cygwin, but you should switch to the aforementioned
automatic translation, unless you have very specific needs. Again,
see <xref linkend="ntsec-mapping"></xref> for the details.</para>
<para>Do you still remember the SIDs with special meaning? In offical
notation they are called "well-known SIDs". For example, POSIX has no GID
for the group of "all users" or "world" or "others". The last three rwx
bits in a unix-style permission value just represent the permissions for
"everyone who is not the owner or is member of the owning group".
Windows has a SID for these poor souls, the "Everyone" SID. Other
well-known SIDs represent circumstances under which a process is
running, rather than actual users or groups. Here are a few examples
for well-known SIDs:</para>
<screen>
Everyone S-1-1-0 Simply everyone...
Batch S-1-5-3 Processes started via the task
scheduler are member of this group.
Interactive S-1-5-4 Only processes of users which are
logged in via an interactive
session are members here.
Authenticated Users S-1-5-11 Users which have gone through
the authentication process and
survived. Anonymously accessing
users are not incuded here.
SYSTEM S-1-5-18 A special account which has all
kinds of dangerous rights, sort of
an uber-root account.
</screen>
<para>For a full list please refer to the MSDN document <ulink
url="http://msdn.microsoft.com/en-us/library/aa379649.aspx">Well-known
SIDs</ulink>. The Cygwin package called "csih" provides a tool,
/usr/lib/csih/getAccountName.exe, which can be used to print the
(possibly localized) name for the various well-known SIDS.</para>
<para>Naturally, well-known SIDs are the same on each machine, so they are
not unique to a machine or domain. They have the same meaning across
the Windows network.</para>
<para>Additionally, there are a couple of well-known builtin groups,
which have the same SID on every machine and which have certain user
rights by default:</para>
<screen>
administrators S-1-5-32-544
users S-1-5-32-545
guests S-1-5-32-546
...
</screen>
<para>For instance, every account is usually member in the "Users"
group. All administrator accounts are member of the "Administrators"
group. That's all about it as far as single machines are involved. In
a domain environment it's a bit more tricky. Since these SIDs are not
unique to a machine, every domain user and every domain group can be a
member of these well known groups. Consider the domain group "Domain
Admins". This group is by default in the "Administrators" group. Let's
assume the above computer called "foo" is a member machine of the domain
"bar.local". If you stick the user "BAR\johndoe" into the group "Domain
Admins", this guy will automatically be a member of the administrators
group on "foo" when logging on to "foo". Neat, isn't it?</para>
<para>Back to ACE and ACL. POSIX is able to create three different
permissions, the permissions for the owner, for the group and for the
world. In contrast the Windows ACL has a potentially infinite number of
members... as long as they fit into 64K. Every member is an ACE.
ACE consist of three parts:</para>
<itemizedlist spacing="compact">
<listitem><para>The type of the ACE (allow ACE or deny ACE).</para></listitem>
<listitem><para>Permission bits, 32 of them.</para></listitem>
<listitem><para>The SID for which the permissions are allowed or denied.</para></listitem>
</itemizedlist>
<para>The two (for us) important types of ACEs are the "access allowed
ACE" and the "access denied ACE". As the names imply, the allow ACE
tells the system to allow the given permissions to the SID, the deny ACE
results in denying the specific permission bits.</para>
<para>The possible permissions on objects are more detailed than in
POSIX. For example, the permission to delete an object is different
from the permission to change object data, and even changing object data
can be separated into different permission bits for different kind of
data. But there's a problem with the definition of a "correct" ACL
which disallows mapping of certain POSIX permissions cleanly. See
<xref linkend="ntsec-mapping"></xref>.</para>
<para>POSIX is able to create only three different permissions? Not quite.
Newer operating systems and file systems on POSIX systems also provide
access control lists. Two different APIs exist for accessing these
ACLs, the Solaris API and the POSIX API. Cygwin implements the Solaris
API to access Windows ACLs in a Unixy way. Online man pages for the
Solaris ACL API can be found on
<ulink url="http://docs.sun.com">http://docs.sun.com</ulink>.</para>
</sect2>
<sect2 id="ntsec-mapping"><title id="ntsec-mapping.title">Mapping Windows accounts to POSIX accounts</title>
<para>
For as long as Cygwin has existed, it has stored user and group information in
<filename>/etc/passwd</filename> and <filename>/etc/group</filename> 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
<filename>/etc/passwd</filename> and <filename>/etc/group</filename>.
</para>
<para>
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.
</para>
<para>
On the other hand, we have to have this mapping between Windows SIDs and
POSIX uid/gid values, so we rely on some mechanism to convert SIDs to uid/gid
values and vice versa.
</para>
<para>
Microsoft "Services for UNIX" (SFU) (deprecated since Windows 8/Server 2012)
never used passwd/group files. Rather, SFU used a fixed, computational mapping
between SIDs and POSIX uid/gid which even has Active Directory support. 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.
</para>
<para>
Starting with Cygwin 1.7.33, Cygwin utilizes an approach inspired by the
mapping method as implemented by SFU, with a few differences for backward
compatibility and to handle some border cases differently.
</para>
<sect3 id="ntsec-mapping-how"><title id="ntsec-mapping-how.title">Mapping Windows SIDs to POSIX uid/gid values</title>
<para>
The following description assumes you're comfortable with the concept of
Windows SIDs and RIDs. For a brief introduction, see
<xref linkend="ntsec-common"></xref>.
</para>
<para>
Cygwin's mapping between SIDs and uid/gid values works in two ways.
</para>
<itemizedlist spacing="compact">
<listitem><para>Read <filename>/etc/passwd<filename> and
</filename>/etc/group</filename> files, just as in the olden days, mainly for
backward compatibility.</para></listitem>
<listitem><para>If no files are present, or if an entry is missing in the files,
ask Windows.</para></listitem>
</itemizedlist>
<para>
At least, that's the default behaviour now. It will be configurable
using a file <filename>/etc/nsswitch.conf</filename>, which is discussed in
<xref linkend="ntsec-mapping-nsswitch"></xref>. Let's explore the default
for now.
</para>
<para>
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.
</para>
<para>
If no entry is found, or no passwd or group file was present, Cygwin
will ask the OS.
</para>
<note>
<para>
If the first process in a Cygwin process tree determines that no
<filename>/etc/passwd</filename> or <filename>/etc/group</filename> 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.
</para>
<para>
For the same reason, if you delete the <filename>/etc/passwd</filename>
or <filename>/etc/group</filename> file, this will be ignored. The passwd
and group records read from the files will persist in memory until either a
new <filename>/etc/passwd</filename> or <filename>/etc/group</filename>
is created, or you exit all processes in the current process tree.
</para>
<para>
See the note in <xref linkend="ntsec-mapping-nsswitch"></xref> for some
comprehensive examples.
</para>
</note>
<para>
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
<ulink url="http://msdn.microsoft.com/en-us/library/windows/desktop/aa379166%28v=vs.85%29.aspx">LookupAccountSid</ulink>
and
<ulink url="http://msdn.microsoft.com/en-us/library/windows/desktop/aa379159%28v=vs.85%29.aspx">LookupAccountName</ulink>
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...
</para>
<para>
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.
</para>
<para>
Let's discuss the SID&lt;=&gt;uid/gid mapping first. Here's how it works.
</para>
<itemizedlist spacing="compact">
<listitem>
<para>
<ulink url="http://msdn.microsoft.com/en-us/library/aa379649.aspx">Well-known
SIDs</ulink>
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. Examples:
</para>
<screen>
"SYSTEM" S-1-5-18 &lt;=&gt; uid/gid: 18
"Users" S-1-5-32-545 &lt;=&gt; uid/gid: 545
</screen>
</listitem>
<listitem>
<para>
Other well-known SIDs in the NT_AUTHORITY domain (S-1-5-X-RID):
</para>
<screen>
S-1-5-X-RID &lt;=&gt; uid/gid: 0x1000 * X + RID
</screen>
<para>Example:</para>
<screen>
"NTLM Authentication" S-1-5-64-10 &lt;=&gt; uid/gid: 0x4000A == 262154
</screen>
</listitem>
<listitem><para>
Other well-known SIDs:
</para>
<screen>
S-1-X-Y &lt;=&gt; uid/gid: 0x10000 + 0x100 * X + Y
</screen>
<para>Example:</para>
<screen>
"LOCAL" S-1-2-0 &lt;=&gt; uid/gid: 0x10200 == 66048
"Creator Group" S-1-3-1 &lt;=&gt; uid/gid: 0x10301 == 66305
</screen>
</listitem>
<listitem>
<para>
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".
</para>
</listitem>
<listitem>
<para>
Mandatory Labels:
</para>
<screen>
S-1-16-RID &lt;=&gt; uid/gid: 0x60000 + RID
</screen>
<para>Example:</para>
<screen>
"Medium Mandatory Level" S-1-16-8192 &lt;=&gt; uid/gid: 0x62000 == 401408
</screen>
</listitem>
<listitem>
<para>
Accounts from the local machine's user DB (SAM):
</para>
<screen>
S-1-5-21-X-Y-Z-RID &lt;=&gt; uid/gid: 0x30000 + RID
</screen>
<para>Example:</para>
<screen>
"Administrator" S-1-5-21-X-Y-Z-500 &lt;=&gt; uid/gid: 0x301f4 == 197108
</screen>
</listitem>
<listitem>
<para>
Accounts from the machine's primary domain:
</para>
<screen>
S-1-5-21-X-Y-Z-RID &lt;=&gt; uid/gid: 0x100000 + RID
</screen>
<para>Example:</para>
<screen>
"Domain Users" S-1-5-21-X-Y-Z-513 &lt;=&gt; uid/gid: 0x100201 == 1049089
</screen>
</listitem>
<listitem>
<para>
Accounts from a trusted domain of the machine's primary domain:
</para>
<screen>
S-1-5-21-X-Y-Z-RID &lt;=&gt; uid/gid: trustPosixOffset(domain) + RID
</screen>
<para>
<literal>trustPosixOffset</literal>? 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
<emphasis>this</emphasis> domain trusts the <emphasis>other</emphasis> domain.
One attribute of a trust is a 32 bit value called
<literal>trustPosixOffset</literal> For each new trust,
<literal>trustPosixOffset</literal> will get some automatic value. In recent
AD domain implementations, the first trusted domain will get
<literal>trustPosixOffset</literal> set to 0x80000000. Following domains will
get lower values. Unfortunately the domain admins are allowed to set the
<literal>trustPosixOffset</literal> value for each trusted domain to some
arbitrary 32 bit value, no matter what the other
<literal>trustPosixOffset</literal> are set to, thus allowing any kind of
collisions between the <literal>trustPosixOffset</literal> values of domains.
That's not exactly helpful, but as the user of this value, we have to
<emphasis>trust</emphasis> the domain admins to set
<literal>trustPosixOffset</literal> to sensible values, or to keep it at the
system chosen defaults.
</para>
<para>
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
</para>
<screen>
S-1-5-21-X-Y-Z-1234 &lt;=&gt; uid/gid 0x800004d2 == 2147484882
</screen>
<para>
There's one problem with this approach. Assuming you're running in the context
of a local SAM user on a domain member machine. Local users don't have the
right to fetch this kind of domain information from the DC, they'll get
permission denied. In this case Cygwin will fake a sensible
<literal>trustPosixOffset</literal> value.
</para>
<para>
Another problem is if the AD administrators chose an unreasonable small
<literal>trustPosixOffset</literal> value. Anything below the hexadecimal
value 0x100000 (the POSIX offset of the primary domain) is bound to produce
collisions with system accounts as well as local accounts. The right thing
to do in this case is to notify your administrator of the problem and to ask
for moving the offset to a more reasonable value. However, to reduce the
probability for collisions, Cygwin overrides this offset with a sensible
fixed replacement offset.
</para>
</listitem>
<listitem>
<para>
Local accounts from another machine in the network:
</para>
<para>
There's no SID&lt;=&gt;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 <literal>trustPosixOffset</literal>, and
there's the additional problem that the
<ulink url="http://msdn.microsoft.com/en-us/library/windows/desktop/aa379166%28v=vs.85%29.aspx">LookupAccountSid</ulink>
and
<ulink url="http://msdn.microsoft.com/en-us/library/windows/desktop/aa379159%28v=vs.85%29.aspx">LookupAccountName</ulink>
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
<literal>Permission denied</literal> error when trying to ask the machine
for its local account.
</para>
</listitem>
</itemizedlist>
<para>
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, <literal>+</literal>.
</para>
<itemizedlist spacing="compact">
<listitem>
<para>
Well-known and builtin accounts will be named as in Windows:
</para>
<screen>
"SYSTEM", "LOCAL", "Medium Mandatory Level", ...
</screen>
</listitem>
<listitem>
<para>
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:
</para>
<screen>
"corinna", "bigfoot", "None", ...
</screen>
</listitem>
<listitem>
<para>
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:
</para>
<screen>
"corinna", "bigfoot", "Domain Users", ...
</screen>
<para>
while accounts from other domains are prepended by their domain:
</para>
<screen>
"DOMAIN1+corinna", "DOMAIN2+bigfoot", "DOMAIN3+Domain Users", ...
</screen>
</listitem>
<listitem>
<para>
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:
</para>
<screen>
"MYMACHINE+corinna", "MYMACHINE+bigfoot", "MYMACHINE+None", ...
</screen>
</listitem>
<listitem>
<para>
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:
</para>
<screen>
"MY_DOM+User(1234)", "MY_DOM+Group(5678)"
</screen>
<para>
Otherwise we know nothing about this SID, so it will be mapped to the
fake accounts <literal>Unknown+User</literal>/<literal>Unknown+Group</literal>
with uid/gid -1.
</para>
</listitem>
</itemizedlist>
</sect3>
<sect3 id="ntsec-mapping-passwdinfo"><title id="ntsec-mapping-passwdinfo.title">Cygwin user names, home dirs, login shells</title>
<para>
Obviously, if you don't maintain <filename>passwd</filename> and
<filename>group</filename> files, you need to have a way to maintain the other
fields of a passwd entry as well. Three things come to mind:
</para>
<itemizedlist spacing="compact">
<listitem>
<para>
You want to use a Cygwin username different from your Windows username.
</para>
<note><para>
Note: This is only supported via <filename>/etc/passwd</filename> and
<filename>/etc/group</filename> files. A Cygwin username maintained in
the Windows user databases would require very costly (read: slow) seach
operations.
</para></note>
</listitem>
<listitem>
<para>
You want a home dir different from the default <filename>/home/$USER</filename>.
</para>
</listitem>
<listitem>
<para>
You want to specify a different login shell than <filename>/bin/bash</filename>.
</para>
</listitem>
</itemizedlist>
<para>
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 <literal>bigfoot</literal> and your domain is
<literal>MY_DOM</literal>. Your default passwd entry <!-- in absence of
anything I'll describe below -->looks like this:
</para>
<screen>
bigfoot:*:&lt;uid&gt;:&lt;gid&gt;:U-MY_DOM\bigfoot,S-1-5-....:/home/bigfoot:/bin/bash
</screen>
<para>
or, if your account is from a different domain than the primary domain of
the machine:
</para>
<screen>
MY_DOM+bigfoot:*:&lt;uid&gt;:&lt;gid&gt;:U-MY_DOM\bigfoot,S-1-5-....:/home/bigfoot:/bin/bash
</screen>
<para>
Yes, the default homedir is still /home/bigfoot.
</para>
<para>
If your account is a domain account:
</para>
<itemizedlist spacing="compact">
<listitem>
<para>
Either create an <filename>/etc/passwd</filename> and/or
<filename>/etc/group</filename> file with entries for your account and tweak
that,
</para>
</listitem>
<listitem>
<para>
or Cygwin will utilize the
<literal>posixAccount</literal>/<literal>posixGroup</literal> attributes per
<ulink url="https://tools.ietf.org/html/rfc2307">RFC 2307</ulink>. These
attributes are by default available in Active Directory since Windows Server
2003 R2. They are <literal>not set</literal>, unless utilized by the
(deprecated since Server 2012 R2) Active Directory "Server for NIS" feature.
The user attributes utilized by Cygwin are:
</para>
<segmentedlist><?dbhtml list-presentation="table"?>
<seglistitem>
<seg><literal>unixHomeDirectory</literal></seg>
<seg>If set, will be used as Cygwin home directory.</seg>
</seglistitem>
<seglistitem>
<seg><literal>loginShell</literal></seg>
<seg>If set, will be used as Cygwin login shell.</seg>
</seglistitem>
<seglistitem>
<seg><literal>gecos</literal></seg>
<seg>Content will be added to the pw_gecos field.</seg>
</seglistitem>
<seglistitem>
<seg><literal>uidNumber</literal></seg>
<seg>See <xref linkend="ntsec-mapping-nfs"></xref>.</seg>
</seglistitem>
<seglistitem>
<seg>The group attributes utilized by Cygwin are:</seg>
</seglistitem>
<seglistitem>
<seg><literal>gidNumber</literal></seg>
<seg>See <xref linkend="ntsec-mapping-nfs"></xref>.</seg>
</seglistitem>
</segmentedlist>
<para>
Apart from power shell scripting or inventing new CLI tools, these attributes
can be changed using the <literal>Attribute Editor</literal> tab in the user
properties dialog of the <literal>Active Directory Users and Computers</literal>
MMC snap-in. Alternatively, if the <literal>Server for NIS</literal>
administration feature has been installed, there will be a
<literal>UNIX Attributes</literal> tab which contains the required fields,
except for the gecos field, which isn't really important anyway. Last resort
is <literal>ADSI Edit</literal>.
</para>
<para>
The primary group of a user is always the Windows primary group set in
Active Directory and can't be changed.
</para>
</listitem>
</itemizedlist>
<para>
If your machine is not a domain member machine or your account is a
local account for some reason:
</para>
<itemizedlist spacing="compact">
<listitem>
<para>
Either create an <filename>/etc/passwd</filename> and/or
<filename>/etc/group</filename> file with entries for your account and tweak
that,
</para>
</listitem>
<listitem>
<para>
or enter the information into the comment field of your local user entry.
In the <literal>Local Users and Groups</literal> MMC snap-in it's called
<literal>Description</literal>.
</para>
<para>
You can utilize this field even if you're running a "home edition" of
Windows, using the command line. The <command>net user</command> command
allows to set all values in the SAM, even if the GUI is crippled.
</para>
<para>
A Cygwin SAM comment entry looks like this:
</para>
<screen>
&lt;cygwin key="value" key="value" [...] /&gt;
</screen>
<para>
The supported keys are:
</para>
<segmentedlist><?dbhtml list-presentation="table"?>
<seglistitem>
<seg><literal>home="value"</literal></seg>
<seg>Sets the Cygwin home dir to value.</seg>
</seglistitem>
<seglistitem>
<seg><literal>shell="value"</literal></seg>
<seg>Sets the Cygwin login shell to value.</seg>
</seglistitem>
<seglistitem>
<seg><literal>group="value"</literal></seg>
<seg>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".</seg>
</seglistitem>
<seglistitem>
<seg><literal>unix="value"</literal></seg>
<seg>Sets the NFS/Samba uid of the user to the decimal value.
See <xref linkend="ntsec-mapping-nfs"></xref>.</seg>
</seglistitem>
</segmentedlist>
<para>
The &lt;cygwin .../&gt; string can start at any point in the comment, but
you have to follow the rules:
</para>
<itemizedlist spacing="compact">
<listitem>
It starts with "&lt;cygwin " and ends with "/&gt;".
</listitem>
<listitem>
The "cygwin" string and the key names have to be lowercase.
</listitem>
<listitem>
No spaces between key and "value", just the equal sign.
</listitem>
<listitem>
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!
</listitem>
</itemizedlist>
<para>
CMD example:
</para>
<screen>
net user corinna /comment:"&lt;cygwin home=\"/home/foo\"/&lt;"
</screen>
<para>
Bash example (use single quotes):
</para>
<screen>
net user corinna /comment:'&lt;cygwin home="/home/foo"/&gt;'
</screen>
<para>
For changing group comments, use the `net localgroup' command. The supported
key/value pair for groups are:
</para>
<segmentedlist><?dbhtml list-presentation="table"?>
<seglistitem>
<seg><literal>unix="value"</literal></seg>
<seg>Sets the NFS/Samba gid of the group to the decimal value.
See <xref linkend="ntsec-mapping-nfs"></xref>.</seg>
</seglistitem>
</segmentedlist>
</listitem>
</itemizedlist>
</sect3>
<sect3 id="ntsec-mapping-caching"><title id="ntsec-mapping-caching.title">Caching account information</title>
<para>
The information fetched from file or the Windows account database is cached
by the process. The cached information is inherited by child processes.
</para>
<para>
While usually working fine, this has some drawbacks. Consider a shell calling
<command>id</command>. <command>id</command> fetches all group information
from the current token and caches them. Unfortunately <command>id</command>
doesn't start any child processes, so the information is lost as soon as
<command>id</command> exits.
</para>
<para>
But there's another caching mechanism available. If
<command><link linkend="using-cygserver">cygserver</link></command> 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
<command><link linkend="using-cygserver">cygserver</link></command>. So, if
you start a Cygwin Terminal and
<command><link linkend="using-cygserver">cygserver</link></command> is running
at the time, <command>mintty</command>, the shell, and all child processes will
use <command><link linkend="using-cygserver">cygserver</link></command> caching.
If you start a Cygwin Terminal and
<command><link linkend="using-cygserver">cygserver</link></command> is not
running a the time, none of the processes started inside this terminal window
will use <command><link linkend="using-cygserver">cygserver</link></command>
caching.
</para>
<para>
The advantage of
<command><link linkend="using-cygserver">cygserver</link></command> caching is
that it's system-wide and, as long as
<command><link linkend="using-cygserver">cygserver</link></command> is running,
unforgetful. Every Cygwin process on the system will have the
<command><link linkend="using-cygserver">cygserver</link></command> cache at
its service. Additionally, all information requested from
<command><link linkend="using-cygserver">cygserver</link></command> once, will
be cached inside the process itself and, again, propagated to child processes.
</para>
</sect3>
<sect3 id="ntsec-mapping-nfs"><title id="ntsec-mapping-nfs.title">NFS account mapping</title>
<para>
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 <ulink url="https://tools.ietf.org/html/rfc1813">RFC 1813</ulink>
compatible NFSv3 stat information from the share. This is what Cygwin is
using to show stat information for files on NFS shares.
</para>
<para>
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.
</para>
<para>
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
<ulink url="http://blogs.technet.com/b/filecab/archive/2012/10/09/nfs-identity-mapping-in-windows-server-2012.aspx">NFS Identity Mapping in Windows Server 2012</ulink>
</para>
<para>
Cygwin now utilizes the
<ulink url="https://tools.ietf.org/html/rfc2307">RFC 2307</ulink>
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
<ulink url="https://tools.ietf.org/html/rfc2307">RFC 2307</ulink>, the uid is
in the attribute <literal>uidNumber</literal>. For groups, the gid is in the
<literal>gidNumber</literal> attribute.
</para>
<para>
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.
</para>
<itemizedlist spacing="compact">
<listitem>
If the server is an AD domain controller, it asks for an account with
<literal>uidNumber</literal> attribute == <literal>st_uid</literal> 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 <literal>uidNumber</literal> attribute. For
groups, the method is the same, just that Cygwin asks for a group with
<literal>gidNumbe</literal> attribute == <literal>st_gid</literal> field of the
stat record.
</listitem>
<listitem>
If the server is a standalone LDAP mapping server Cygwin asks for the
same <literal>uidNumber</literal>/<literal>gidNumber</literal> 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.
</listitem>
</itemizedlist>
<para>
The mapping will be cached for the lifetime of the process, and inherited
by child processes.
</para>
</sect3>
<sect3 id="ntsec-mapping-samba"><title id="ntsec-mapping-samba.title">Samba account mapping</title>
<para>
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.
</para>
<para>
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:
</para>
<itemizedlist spacing="compact">
<listitem>
A UNIX user account with uid X is mapped to the Windows SID S-1-22-1-X.
</listitem>
<listitem>
A UNIX group account with gid X is mapped to SID S-1-22-2-X.
</listitem>
</itemizedlist>
<para>
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?
</para>
<para>
That's what Cygwin will do. If it encounters a S-1-22-x-y SID, it
will perform the same
<ulink url="https://tools.ietf.org/html/rfc2307">RFC 2307</ulink>
mapping as for NFS shares.
</para>
<para>
For home users without any Windows domain or LDAP server per
<ulink url="https://tools.ietf.org/html/rfc2307">RFC 2307</ulink>,
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.
</para>
<para>
To your user's SAM comment (remember: called <literal>Description</literal>
in the GUI),
add:
</para>
<screen>
&lt;cygwin group="Users" unix="505"/&gt;
</screen>
<para>
To the user's group SAM comment add:
</para>
<screen>
&lt;cygwin unix="100"/&gt;
</screen>
<para>
This should be sufficient to work on your Samba share and to see
all files owned by your Linux user account as your files.
</para>
</sect3>
<sect3 id="ntsec-mapping-nsswitch"><title id="ntsec-mapping-nsswitch.title">The <filename>/etc/nsswitch.conf</filename> file</title>
<para>
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
<ulink url="http://linux.die.net/man/5/nsswitch.conf">/etc/nsswitch.conf</ulink>.
One part of it is to specify how the passwd and group entries are generated.
That's what Cygwin now provides as well.
</para>
<para>
The <filename>/etc/nsswitch.conf</filename> file is optional. If you don't
have one, Cygwin uses sensible defaults.
</para>
<note>
<para>
The <filename>/etc/nsswitch.conf</filename> file is read exactly once by
the first process of a Cygwin process tree. If there was no
<filename>/etc/nsswitch.conf</filename> file when this first process started,
then no other process in the running Cygwin process tree will try to read the
file.
</para>
<para>
If you create or change <filename>/etc/nsswitch.conf</filename>, you have 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.
</para>
<para>
For example, if you run <command>vim</command> inside the default Cygwin
Terminal, <command>vim</command> is a child of your shell, which is a child
of <command>mintty</command>. If you edit
<filename>/etc/nsswitch.conf</filename> in that <command>vim</command>
instance, your shell won't immediately see the change, nor will
<command>vim</command> if you restart it from that same shell instance.
This is because both are getting their nsswitch information from their
ancestor, <command>mintty</command>. You have to start a fresh terminal
window for the change to take effect.
</para>
<para>
By contrast, if you leave that Cygwin Terminal window open after making the
change to <filename>/etc/nsswitch.conf</filename>, then restart a Cygwin
service like <command>cron</command>, <command>cron</command> will see the
change, because it is not a child of <command>mintty</command> or any other
Cygwin process. (Technically, it is a child of <command>cygrunsrv</command>,
but that instance also restarts when you restart the service.)
</para>
<para>
The reason we point all this out is that the requirements for restarting
things are not quite as stringent as when you replace
<filename>cygwin1.dll</filename>. 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.
</para>
</note>
<para>
So, what settings can we perform with <filename>/etc/nsswitch.conf</filename>?
To explain, lets have a look into an <filename>/etc/nsswitch.conf</filename>
file set up to all default values:
</para>
<screen>
# /etc/nsswitch.conf
passwd: files db
group: files db
<!--
db_prefix: auto
db_separator: + -->
db_enum: cache builtin
</screen>
<para>
The first line, starting with a hash <literal>#</literal> 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:
</para>
<screen>
foo: bar # baz
</screen>
<para>
means, set "foo" to value "bar", ignore everything after the hash.
</para>
<para>
The other lines define the available settings. The first word up to a
colon is a keyword. Note that the colon <emphasis>must</emphasis> follow
immediately after the keyword. This is a valid line:
</para>
<screen>
foo: bar
</screen>
<para>
This is not valid:
</para>
<screen>
foo : bar
</screen>
<para>
Apart from this restriction, the reminder of the line can have as
many spaces and TABs as you like.
</para>
<para>
Now let's have a look at the available keywords and settings.
</para>
<para>
The two lines starting with the keywords <literal>passwd:</literal> and
<literal>group:</literal> define where Cygwin gets its passwd and group
information from. <literal>files</literal> means, fetch the information
from the corresponding file in the /etc directory. <literal>db</literal>
means, fetch the information from the Windows account databases, the SAM
for local accounts, Active Directory for domain account. Examples:
</para>
<screen>
passwd: files
</screen>
<para>
Read passwd entries only from /etc/passwd.
</para>
<screen>
group: db
</screen>
<para>
Read group entries only from SAM/AD.
</para>
<screen>
group: files # db
</screen>
<para>
Read group entries only from <filename>/etc/group</filename>
(<literal>db</literal> is only a comment).
</para>
<screen>
passwd: files db
</screen>
<para>
Read passwd entries from <filename>/etc/passwd</filename>. 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.
</para>
<screen>
group: db files
</screen>
<para>
This is a valid entry, but the order will be ignored by Cygwin. If both,
<literal>files</literal> and <literal>db</literal> are specified, Cygwin will
always try the files first, then the db.
</para>
<para>
The remaining entries define certain aspects of the Windows account
database search. Right now, only one entry is valid:
</para>
<itemizedlist spacing="compact">
<!--
<listitem>
<para>
<literal>db_prefix:</literal> determines how the Cygwin user or group name
is created. The recognized values are:
</para>
<variablelist>
<varlistentry>
<term><literal>auto</literal></term>
<listitem>
<para>
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.
</para>
<para>
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:
</para>
<segmentedlist><?dbhtml list-presentation="table"?>
<seglistitem>
<seg><literal>MY_DOM+username</literal></seg>
<seg>(foreign domain)</seg>
</seglistitem>
<seglistitem>
<seg><literal>MACHINE+username</literal></seg>
<seg>(local account)</seg>
</seglistitem>
</segmentedlist>
<para>
Builtin accounts are simply used as is:
</para>
<segmentedlist><?dbhtml list-presentation="table"?>
<seglistitem>
<seg><literal>LOCAL</literal></seg>
</seglistitem>
<seglistitem>
<seg><literal>Users</literal></seg>
</seglistitem>
</segmentedlist>
<para>
Unknown accounts on NFS or Samba shares (that is, accounts which cannot be
mapped to Windows user accounts via
<ulink url="https://tools.ietf.org/html/rfc2307">RFC 2307</ulink>) get a
Cygwin account name consisting of the artificial domains
<literal>Unix_User</literal> or <literal>Unix_Group</literal> and the
uid/gid value, for instance:
</para>
<segmentedlist><?dbhtml list-presentation="table"?>
<seglistitem>
<seg><literal>Unix_User+0</literal></seg>
<seg>(root)</seg>
</seglistitem>
<seglistitem>
<seg><literal>Unix_Group+10</literal></seg>
<seg>(wheel)</seg>
</seglistitem>
</segmentedlist>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>primary</literal></term>
<listitem>
<para>
Like <literal>auto</literal>, but primary domain accounts will be
prepended by the domainname as well.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>always</literal></term>
<listitem>
<para>
All accounts, even the builtin accounts, will have the domain name
prepended:
</para>
<segmentedlist><?dbhtml list-presentation="table"?>
<seglistitem>
<seg><literal>BUILTIN+Users</literal></seg>
</seglistitem>
</segmentedlist>
<para>
A special case are builtin accounts which have an emtpy domain name.
These will be prependend by just the separator character in
<literal>always</literal> mode:
</para>
<segmentedlist><?dbhtml list-presentation="table"?>
<seglistitem>
<seg><literal>+LOCAL</literal></seg>
</seglistitem>
</segmentedlist>
</listitem>
</varlistentry>
</variablelist>
</listitem>
<listitem>
<para>
<literal>db_separator:</literal> defines the spearator char used to prepend the
domain name to the user or group name. The default is the plus character
<literal>+</literal>.
</para>
<screen>
MY_DOM+username
</screen>
<para>
With <literal>db_separator:</literal>, you can define any ASCII char except
space, tab, carriage return, line feed, and the colon, as separator char.
Example:
</para>
<screen>
db_separator: \
</screen>
<para>
This results in usernames with the backslash as separator:
</para>
<screen>
MY_DOM\username
</screen>
</listitem>
-->
<listitem>
<para>
<literal>db_enum:</literal> defines the depth of a database search, if an
application calls one of the enumeration functions
<ulink url="http://linux.die.net/man/3/getpwent">getpwent</ulink>
or <ulink url="http://linux.die.net/man/3/getgrent">getgrent</ulink>.
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 <filename>/etc/passwd</filename> and <filename>/etc/group</filename>
files existed and the number of user accounts on a typical UNIX system was
seldomly a three-digit number.
</para>
<para>
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.
</para>
<para>
<literal>db_enum:</literal> allows to specify the accounts to enumerate in a
fine-grained manner. It takes a list of sources as argument:
</para>
<screen>
db_enum: source1 source2 ...
</screen>
<para>
The recognized sources are the following:
</para>
<variablelist>
<varlistentry>
<term><literal>none</literal></term>
<listitem>No output from
<function>getpwent</function>/<function>getgrent</function>
at all.</listitem>
</varlistentry>
<varlistentry>
<term><literal>all</literal></term>
<listitem>The opposite. Enumerates accounts from all known sources, including
all trusted domains.</listitem>
</varlistentry>
<varlistentry>
<term><literal>cache</literal></term>
<listitem>Enumerate all accounts currently cached in memory.</listitem>
</varlistentry>
<varlistentry>
<term><literal>builtin</literal></term>
<listitem>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).</listitem>
</varlistentry>
<varlistentry>
<term><literal>files</literal></term>
<listitem>Enumerate the accounts from <filename>/etc/passwd</filename> or
<filename>/etc/group</filename>.</listitem>
</varlistentry>
<varlistentry>
<term><literal>local</literal></term>
<listitem>Enumerate all accounts from the local SAM.</listitem>
</varlistentry>
<varlistentry>
<term><literal>primary</literal></term>
<listitem>Enumerate all accounts from the primary domain.</listitem>
</varlistentry>
<varlistentry>
<term><literal>alltrusted</literal></term>
<listitem>Enumerate all accounts from all trusted domains.</listitem>
</varlistentry>
<varlistentry>
<term><literal>some.domain</literal></term>
<listitem>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.</listitem>
</varlistentry>
</variablelist>
<para>
Please note that <function>getpwent</function>/<function>getgrent</function>
do <emphasis>not</emphasis> 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 <filename>/etc/nsswitch.conf</filename>:
</para>
<screen>
db_enum: none
</screen>
<para>
No output from <function>getpwent</function>/<function>getgrent</function>
at all. The first call to the function immediately returns a NULL pointer.
</para>
<screen>
db_enum: cache files
</screen>
<para>
Enumerate all accounts cached by the current process, plus all entries
from either the /etc/passwd or /etc/group file.
</para>
<screen>
db_enum: cache local primary
</screen>
<para>
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.
</para>
<screen>
db_enum: local primary alltrusted
</screen>
<para>
Enumerate the accounts from the machine's SAM, from the primary domain of the
machine, and from all trusted domains.
</para>
<screen>
db_enum: primary domain1.corp sub.domain.corp domain2.net
</screen>
<para>
Enumerate the accounts from the primary domain and from the domains
domain1.corp, sub.domain.corp and domain2.net.
</para>
<screen>
db_enum: all
</screen>
<para>
Enumerate everything and the kitchen sink.
</para>
</listitem>
</itemizedlist>
</sect3>
</sect2>
<sect2 id="ntsec-files"><title id="ntsec-files.title">File permissions</title>
<para>On NTFS and if the <literal>noacl</literal> mount option is not
specified for a mount point, Cygwin sets file permissions as on POSIX
systems. Basically this is done by defining a Security Descriptor with the
matching owner and group SIDs, and a DACL which contains ACEs for the owner,
the group and for "Everyone", which represents what POSIX calls "others".</para>
<para>There's just one problem when trying to map the POSIX permission model
onto the Windows permission model.</para>
<para>There's a leak in the definition of a "correct" ACL which disallows a
certain POSIX permission setting. The official documentation explains in short
the following:</para>
<itemizedlist spacing="compact">
<listitem><para>The requested permissions are checked against all
ACEs of the user as well as all groups the user is member of. The
permissions given in these user and groups access allowed ACEs are
accumulated and the resulting set is the set of permissions of that
user given for that object.</para></listitem>
<listitem><para>The order of ACEs is important. The system reads them in
sequence until either any single requested permission is denied or all
requested permissions are granted. Reading stops when this condition is
met. Later ACEs are not taken into account.</para></listitem>
<listitem><para>All access denied ACEs <emphasis
role='bold'>should</emphasis> precede any access allowed ACE. ACLs
following this rule are called "canonical"</para></listitem>
</itemizedlist>
<para>Note that the last rule is a preference or a definition of
correctness. It's not an absolute requirement. All Windows kernels
will correctly deal with the ACL regardless of the order of allow and
deny ACEs. The second rule is not modified to get the ACEs in the
preferred order.</para>
<para>Unfortunately the security tab in the file properties dialog of
the Windows Explorer insists to rearrange the order of the ACEs to
canonical order before you can read them. Thank God, the sort order
remains unchanged if one presses the Cancel button. But don't even
<emphasis role='bold'>think</emphasis> of pressing OK...</para>
<para>Canonical ACLs are unable to reflect each possible combination
of POSIX permissions. Example:</para>
<screen>
rw-r-xrw-
</screen>
<para>Ok, so here's the first try to create a matching ACL, assuming
the Windows permissions only have three bits, as their POSIX counterpart:
</para>
<screen>
UserAllow: 110
GroupAllow: 101
OthersAllow: 110
</screen>
<para>Hmm, because of the accumulation of allow rights the user may
execute because the group may execute.</para>
<para>Second try:</para>
<screen>
UserDeny: 001
GroupAllow: 101
OthersAllow: 110
</screen>
<para>Now the user may read and write but not execute. Better? No!
Unfortunately the group may write now because others may write.</para>
<para>Third try:</para>
<screen>
UserDeny: 001
GroupDeny: 010
GroupAllow: 001
OthersAllow: 110
</screen>
<para>Now the group may not write as intended but unfortunately the user may
not write anymore, either. How should this problem be solved? According to
the canonical order a UserAllow has to follow the GroupDeny but it's
easy to see that this can never be solved that way.</para>
<para>The only chance:</para>
<screen>
UserDeny: 001
UserAllow: 010
GroupDeny: 010
GroupAllow: 001
OthersAllow: 110
</screen>
<para>Again: This works on all existing versions of Windows NT, at the
time of writing from at least Windows XP up to Server 2012 R2. Only
the GUIs aren't able (or willing) to deal with that order.</para>
</sect2>
<sect2 id="ntsec-setuid-overview"><title id="ntsec-setuid-overview.title">Switching the user context</title>
<para>Since Windows XP, Windows users have been accustomed to the
"Switch User" feature, which switches the entire desktop to another user
while leaving the original user's desktop "suspended". Another Windows
feature is the "Run as..." context menu entry, which allows you to start
an application using another user account when right-clicking on applications
and shortcuts.</para>
<para>On POSIX systems, this operation can be performed by processes
running under the privileged user accounts (usually the "root" user
account) on a per-process basis. This is called "switching the user
context" for that process, and is performed using the POSIX
<command>setuid</command> and <command>seteuid</command> system
calls.</para>
<para>While this sort of feature is available on Windows as well,
Windows does not support the concept of these calls in a simple fashion.
Switching the user context in Windows is generally a tricky process with
lots of "behind the scenes" magic involved.</para>
<para>Windows uses so-called `access tokens' to identify a user and its
permissions. Usually the access token is created at logon time and then
it's attached to the starting process. Every new process within a session
inherits the access token from its parent process. Every thread can
get its own access token, which allows, for instance, to define threads
with restricted permissions.</para>
<sect3 id="ntsec-logonuser"><title id="ntsec-logonuser.title">Switching the user context with password authentication</title>
<para>To switch the user context, the process has to request such an access
token for the new user. This is typically done by calling the Win32 API
function <command>LogonUser</command> with the user name and the user's
cleartext password as arguments. If the user exists and the password was
specified correctly, the access token is returned and either used in
<command>ImpersonateLoggedOnUser</command> to change the user context of
the current thread, or in <command>CreateProcessAsUser</command> to
change the user context of a spawned child process.</para>
<para>Later versions of Windows define new functions in this context and
there are also functions to manipulate existing access tokens (usually
only to restrict them). Windows Vista also adds subtokens which are
attached to other access tokens which plays an important role in the UAC
(User Access Control) facility of Vista and later. However, none of
these extensions to the original concept are important for this
documentation.</para>
<para>Back to this logon with password, how can this be used to
implement <command>set(e)uid</command>? Well, it requires modification
of the calling application. Two Cygwin functions have been introduced
to support porting <command>setuid</command> applications which only
require login with passwords. You only give Cygwin the right access
token and then you can call <command>seteuid</command> or
<command>setuid</command> as usual in POSIX applications. Porting such
a <command>setuid</command> application is illustrated by a short
example:</para>
<screen>
<![CDATA[
/* First include all needed cygwin stuff. */
#ifdef __CYGWIN__
#include <windows.h>
#include <sys/cygwin.h>
#endif
[...]
struct passwd *user_pwd_entry = getpwnam (username);
char *cleartext_password = getpass ("Password:");
[...]
#ifdef __CYGWIN__
/* Patch the typical password test. */
{
HANDLE token;
/* Try to get the access token from Windows. */
token = cygwin_logon_user (user_pwd_entry, cleartext_password);
if (token == INVALID_HANDLE_VALUE)
error_exit;
/* Inform Cygwin about the new impersonation token. */
cygwin_set_impersonation_token (token);
/* Cygwin is now able, to switch to that user context by setuid or seteuid calls. */
}
#else
/* Use standard method on non-Cygwin systems. */
hashed_password = crypt (cleartext_password, salt);
if (!user_pwd_entry ||
strcmp (hashed_password, user_pwd_entry->pw_password))
error_exit;
#endif /* CYGWIN */
[...]
/* Everything else remains the same! */
setegid (user_pwd_entry->pw_gid);
seteuid (user_pwd_entry->pw_uid);
execl ("/bin/sh", ...);
]]>
</screen>
</sect3>
<sect3 id="ntsec-nopasswd1"><title id="ntsec-nopasswd1.title">Switching the user context without password, Method 1: Create a token from scratch</title>
<para>An unfortunate aspect of the implementation of
<command>set(e)uid</command> is the fact that the calling process
requires the password of the user to which to switch. Applications such as
<command>sshd</command> wishing to switch the user context after a
successful public key authentication, or the <command>cron</command>
application which, again, wants to switch the user without any authentication
are stuck here. But there are other ways to get new user tokens.</para>
<para>One way is just to create a user token from scratch. This is
accomplished by using an (officially undocumented) function on the NT
function level. The NT function level is used to implement the Win32
level, and, as such is closer to the kernel than the Win32 level. The
function of interest, <command>NtCreateToken</command>, allows you to
specify user, groups, permissions and almost everything you need to
create a user token, without the need to specify the user password. The
only restriction for using this function is that the calling process
needs the "Create a token object" user right, which only the SYSTEM user
account has by default, and which is considered the most dangerous right
a user can have on Windows systems.</para>
<para>That sounds good. We just start the servers which have to switch
the user context (<command>sshd</command>, <command>inetd</command>,
<command>cron</command>, ...) as Windows services under the SYSTEM
(or LocalSystem in the GUI) account and everything just works.
Unfortunately that's too simple. Using <command>NtCreateToken</command>
has a few drawbacks.</para>
<para>First of all, beginning with Windows Server 2003,
the permission "Create a token object" gets explicitly removed from
the SYSTEM user's access token, when starting services under that
account. That requires us to create a new account with this specific
permission just to run this kind of services. But that's a minor
problem.</para>
<para>A more important problem is that using <command>NtCreateToken</command>
is not sufficient to create a new logon session for the new user. What
does that mean? Every logon usually creates a new logon session.
A logon session has a couple of attributes which are unique to the
session. One of these attributes is the fact, that Windows functions
identify the user domain and user name not by the SID of the access
token owner, but only by the logon session the process is running under.</para>
<para>This has the following unfortunate consequence. Consider a
service started under the SYSTEM account (up to Windows XP) switches the
user context to DOMAIN\my_user using a token created directly by calling
the <command>NtCreateToken</command> function. A process running under
this new access token might want to know under which user account it's
running. The corresponding SID is returned correctly, for instance
S-1-5-21-1234-5678-9012-77777. However, if the same process asks the OS
for the user name of this SID something wierd happens. For instance,
the <command>LookupAccountSid</command> function will not return
"DOMAIN\my_user", but "NT AUTHORITY\SYSTEM" as the user name.</para>
<para>You might ask "So what?" After all, this only <emphasis
role='bold'>looks</emphasis> bad, but functionality and permission-wise
everything should be ok. And Cygwin knows about this shortcoming so it
will return the correct Cygwin username when asked. Unfortunately this
is more complicated. Some native, non-Cygwin Windows applications will
misbehave badly in this situation. A well-known example are certain versions
of Visual-C++.</para>
<para>Last but not least, you don't have the usual comfortable access
to network shares. The reason is that the token has been created
without knowing the password. The password are your credentials
necessary for network access. Thus, if you logon with a password, the
password is stored hidden as "token credentials" within the access token
and used as default logon to access network resources. Since these
credentials are missing from the token created with
<command>NtCreateToken</command>, you only can access network shares
from the new user's process tree by using explicit authentication, on
the command line for instance:</para>
<screen>
bash$ net use '\\server\share' /user:DOMAIN\my_user my_users_password
</screen>
<para>Note that, on some systems, you can't even define a drive letter
to access the share, and under some circumstances the drive letter you
choose collides with a drive letter already used in another session.
Therefore it's better to get used to accessing these shares using the UNC
path as in</para>
<screen>
bash$ grep foo //server/share/foofile
</screen>
</sect3>
<sect3 id="ntsec-nopasswd2"><title id="ntsec-nopasswd2.title">Switching the user context without password, Method 2: LSA authentication package</title>
<para>We're looking for another way to switch the user context without
having to provide the password. Another technique is to create an
LSA authentication package. LSA is an acronym for "Local Security Authority"
which is a protected part of the operating system which only allows changes
to become active when rebooting the system after the change. Also, as soon as
the LSA encounters serious problems (for instance, one of the protected
LSA processes died), it triggers a system reboot. LSA is the part of
the OS which cares for the user logons and which also creates logon
sessions.</para>
<para>An LSA authentication package is a DLL which has to be installed
as part of the LSA. This is done by tweaking a special registry key.
Cygwin provides such an authentication package. It has to be installed
and the machine has to be rebooted to activate it. This is the job of the
shell script <filename>/usr/bin/cyglsa-config</filename> which is part of
the Cygwin package.</para>
<para>After running <filename>/usr/bin/cyglsa-config</filename> and
rebooting the system, the LSA authentication package is used by Cygwin
when <command>set(e)uid</command> is called by an application. The
created access token using this method has its own logon session.</para>
<para>This method has two advantages over the <command>NtCreateToken</command>
method.</para>
<para>The very special and very dangerous "Create a token object" user
right is not required by a user using this method. Other privileged
user rights are still necessary, especially the "Act as part of the
operating system" right, but that's just business as usual.</para>
<para>The user is correctly identified, even by delicate native applications
which choke on that using the <command>NtCreateToken</command> method.</para>
<para>Disadvantages? Yes, sure, this is Windows. The access token
created using LSA authentication still lacks the credentials for network
access. After all, there still hasn't been any password authentication
involved. The requirement to reboot after every installation or
deinstallation of the cygwin LSA authentication DLL is just a minor
inconvenience compared to that...</para>
<para>Nevertheless, this is already a lot better than what we get by
using <command>NtCreateToken</command>, isn't it?</para>
</sect3>
<sect3 id="ntsec-nopasswd3"><title id="ntsec-nopasswd3.title">Switching the user context without password, Method 3: With password</title>
<para>Ok, so we have solved almost any problem, except for the network
access problem. Not being able to access network shares without
having to specify a cleartext password on the command line or in a
script is a harsh problem for automated logons for testing purposes
and similar stuff.</para>
<para>Fortunately there is a solution, but it has its own drawbacks.
But, first things first, how does it work? The title of this section
says it all. Instead of trying to logon without password, we just logon
with password. The password gets stored two-way encrypted in a hidden,
obfuscated area of the registry, the LSA private registry area. This
part of the registry contains, for instance, the passwords of the Windows
services which run under some non-default user account.</para>
<para>So what we do is to utilize this registry area for the purpose of
<command>set(e)uid</command>. The Cygwin command <command><link
linkend="passwd">passwd</link> -R</command> allows a user to specify
his/her password for storage in this registry area. When this user
tries to login using ssh with public key authentication, Cygwin's
<command>set(e)uid</command> examines the LSA private registry area and
searches for a Cygwin specific key which contains the password. If it
finds it, it calls <command>LogonUser</command> under the hood, using
this password. If that works, <command>LogonUser</command> returns an
access token with all credentials necessary for network access.</para>
<para>For good measure, and since this way to implement
<command>set(e)uid</command> is not only used by Cygwin but also by
Microsoft's SFU (Services for Unix), we also look for a key stored by
SFU (using the SFU command <command>regpwd</command>) and use that if it's
available.</para>
<para>We got it. A full access token with its own logon session, with
all network credentials. Hmm, that's heaven...</para>
<para>Back on earth, what about the drawbacks?</para>
<para>First, adding a password to the LSA private registry area
requires administrative access. So calling <command>passwd -R</command>
as a normal user will fail! Cygwin provides a workaround for
this. If <command>cygserver</command> is started as a service running
under the SYSTEM account (which is the default way to run
<command>cygserver</command>) you can use <command>passwd -R</command>
as normal, non-privileged user as well.</para>
<para>Second, as aforementioned, the password is two-way encrypted in a
hidden, obfuscated registry area. Only SYSTEM has access to this area
for listing purposes, so, even as an administrator, you can't examine
this area with regedit. Right? No. Every administrator can start
regedit as SYSTEM user:</para>
<screen>
bash$ date
Tue Dec 2 16:28:03 CET 2008
bash$ at 16:29 /interactive regedit.exe
</screen>
<para>Additionally, if an administrator knows under which name
the private key is stored (which is well-known since the algorithms
used to create the Cygwin and SFU keys are no secret), every administrator
can access the password of all keys stored this way in the registry.</para>
<para>Conclusion: If your system is used exclusively by you, and if
you're also the only administrator of your system, and if your system is
adequately locked down to prevent malicious access, you can safely use
this method. If your machine is part of a network which has
dedicated administrators, and you're not one of these administrators,
but you (think you) can trust your administrators, you can probably
safely use this method.</para>
<para>In all other cases, don't use this method. You have been warned.</para>
</sect3>
<sect3 id="ntsec-setuid-impl"><title id="ntsec-setuid-impl.title">Switching the user context, how does it all fit together?</title>
<para>Now we learned about four different ways to switch the user
context using the <command>set(e)uid</command> system call, but
how does <command>set(e)uid</command> really work? Which method does it
use now?</para>
<para>The answer is, all four of them. So here's a brief overview
what <command>set(e)uid</command> does under the hood:</para>
<itemizedlist>
<listitem>
<para>When <command>set(e)uid</command> is called, it tests if the
user context had been switched by an earlier call already, and if the
new user account is the privileged user account under which the process
had been started originally. If so, it just switches to the original
access token of the process it had been started with.</para>
</listitem>
<listitem>
<para>
Next, it tests if an access token has been stored by an earlier call
to <command>cygwin_set_impersonation_token</command>. If so, it tests
if that token matches the requested user account. If so, the stored
token is used for the user context switch.</para>
<para>
If not, there's no predefined token which can just be used for
the user context switch, so we have to create a new token. The order
is as follows.</para>
</listitem>
<listitem>
<para>Check if the user has stored the logon password in the LSA
private registry area, either under a Cygwin key, or under a SFU key.
If so, use this to call <command>LogonUser</command>. If this
succeeds, we use the resulting token for the user context switch.</para>
</listitem>
<listitem>
<para>Otherwise, check if the Cygwin-specifc LSA authentication package
has been installed and is functional. If so, use the appropriate LSA
calls to communicate with the Cygwin LSA authentication package and
use the returned token.</para>
</listitem>
<listitem>
<para>Last chance, try to use the <command>NtCreateToken</command> call
to create a token. If that works, use this token.</para>
</listitem>
<listitem>
<para>If all of the above fails, our process has insufficient privileges
to switch the user context at all, so <command>set(e)uid</command>
fails and returns -1, setting errno to EPERM.</para>
</listitem>
</itemizedlist>
</sect3>
</sect2>
</sect1>
Reference in New Issue View Git Blame Copy Permalink