Permissions In Microsoft Services for UNIX v3.0
Mapping UNIX Permission Bits and Windows Access Rights
Technical Walkthrough
Click here to download a copy of this paper
Abstract
Microsoft Services for UNIX version 3.0 provides several different services such as NFS and Interix which are geared towards enterprise customers wanting to integrate Windows into their existing UNIX®1 systems based environment. The interoperability services, like NFS, allow customers to seamlessly share and access information between multiple platforms. And the UNIX system environment, known as Interix and the Interix subsystem, allows UNIX users to migrate and reuse their application source code and their shell scripts on a Windows system.
Both NFS and Interix provide UNIX system functionality on Windows. But the UNIX file security model is based on a set of nine permission bits while Windows security model is based on a Discretionary Access Control List. This paper describes how these components translate between the UNIX and Windows file permission models.
On This Page
.gif){kind=icon}
Introduction
User and Group Accounts
File Security
File Creation using Interix or NFS Server
Windows To UNIX Mapping
For More Information
Appendix
Introduction
The Windows and UNIX operating systems use inherently different mechanisms for user identification, authentication, and resource access control. Both the operating system and individual users must be able to protect files from unwanted viewing and modification, but methods for accomplishing this differ greatly between UNIX and Windows. In general, the UNIX file security model is straightforward and easy to understand, while Windows file security is considerably more extensive, flexible and powerful.
Windows Services for UNIX (aka SFU) provides UNIX system to Windows system interoperability services including Client for NFS and Server for NFS. These services allow Windows users to access files on UNIX servers and allow UNIX users to access files on Windows systems.
SFU also includes the Interix subsystem technology that provides a complete UNIX system run time and programming environment. Interix is not a standalone UNIX system but is integrated with Windows. Many of the resources and services provided by Windows are accessible from both the Interix and Windows subsystem environments at the same time. Interix provides a complete set of UNIX features, including case sensitive filenames, job control, common UNIX utilities (over 300, including Korn Shell, C shell, awk, X Windows clients) and development tools including make and gcc. Migrating UNIX applications to Windows is as easy (or difficult) as migrating the application between any other two versions of UNIX.
The purpose of this document is to describe how the SFU product components provide the semantics of UNIX file permissions using the Windows Discretionary Access Control (DAC) security mechanism. The document first describes some background information about important aspects of file permissions and related algorithms. Topics such as User and Group Accounts, Windows File Security, Unix File Security and file creation are discussed. The differences in UNIX and Windows algorithms are highlighted in order to better understand the translation process that occurs when mapping between UNIX permission bits and the access rights in a Windows DACL.
User and Group Accounts
In Windows accounts are identified by a name and a globally unique ID known as a Security Identifier or SID. All user and group accounts share a common namespace - no two accounts can have the same SID. A SID is represented by a large variable length number consisting of a DomainSID part and a Relative ID (RID) part. The DomainSID identifies a specific Windows domain. The RID part is a unique small number (only 32 bits) which is used to identify a specific group or user member in a domain. Windows has many domains including a BUILTIN domain, a system local domain and many global trusted domains. The DomainSid is a sufficiently large number that all SIDs can be unique across all domains in the local network. There are some special well-defined SIDs that are members of the special BUILTIN domain and are universal across all Windows systems (Windows NT, Windows 2000, Windows XP and Windows 2003). The SYSTEM user account, the World group account and the Administrators group account are examples of these well-known SIDs. In Windows, accounts are uniquely identified by their SID. Furthermore, within each domain the user and group accounts share the same namespace, so no two names (user or group) can be identical.
In UNIX, user accounts and group accounts are represented by a name and a numerical identifier (ID). These accounts are in separate name spaces so that the same name can be used as a user account and a group account. Additionally, a User ID (UID) and Group ID (GID) could have the same numeric value. User and group IDs are distinguished from each other by the context in which they are used.
With Server for NFS, UNIX IDs received in NFS requests are mapped to Windows SIDs using the User Name Mapping(UNM) service included in SFU. UNM converts incoming IDs to Windows SIDs and converts Windows SIDs to Unix IDs in any outgoing communications. Part of the UNM configuration process requires the import of appropriate UNIX IDs from the external UNIX systems involved. This configuration is performed by an administrator before the NFS server is used.
In Interix, given that it implements a UNIX system environment, it must provide unique 32 bit IDs for use by the Interix applications running on the local system. It does this by using a unique 1:1 mapping algorithm that can transform a Windows SID into a 32 bit number and vice versa. This internal mapping algorithm depends on support from the Windows LSA service2 and is limited to working in environments that have less than 4095 trusted global domains and up to a maximum of 1048575 total user and group accounts in each of these domains.
User and group accounts are used for identification and ownership of files. Files on Windows have an owner and a primary group just like on UNIX. However, on Windows, because user and group accounts share the same namespace, it is possible for the owner of a file to be a group account, and the file’s primary group could be a user account. This results in some interesting behavior when translating between NT and UNIX security permissions that are discussed below.
File Security
Windows and UNIX use inherently different file security mechanisms. In order to understand the mappings between the two, one must first understand the how each works.
Windows File Security
Every file and directory in the Windows NTFS file system has security information associated with it, including an owner security identifier (owner SID), a group security identifier (group SID), a Discretionary Access Control List (DACL), and a set of file attribute flags like ATTRIB_READONLY and ATTRIB_SYSTEM.
The owner SID represents the owner of the file and the owner is always permitted to change or update any part of the file’s attributes including the DACL The group SID is not used in the Windows environment but is required in SFU’s UNIX environments. The DACL consists of zero or more individual Access Control Entries (ACEs). Each ACE contains a SID, an access mask, and some flags that control the inheritance of ACEs. These inheritance flags control how ACEs are propagated from a directory to the files and subdirectories contained within it.
The two ACE’s that are important in this discussion are: access-denied and access-allowed. The access-allowed ACE grants the access rights specified in the ACE’s access mask and the access-denied ACE denies the access rights. The access-denied ACE is enforced regardless of any access-allowed ACE.
Each ACE contains a single SID which means it represents one specific user or group. The access mask, is a set of bits (See Table 2 in Appendix 1), which represents the specific access rights allowed or denied to that particular SID. While NTFS provides an array of specific access rights, normally they are not all indicated by Windows applications. Instead, applications display the names for certain common combinations of access rights, such Read or Change or Full Control. See Table 3 in the Appendix for more examples.
.gif)
Figure 1: A file and its associated DACL
Figure 1 shows a conceptual drawing of a file and its DACL. Several Windows utilities are available to view the DACL information such as the command line tool
called CACLS.EXE and the GUI Windows Explorer utility . From Windows Explorer you select Properties in the File menu and then select the Security tab.
An example of the output from CACLS.EXE is shown below.
$ cacls foobar
C:\foobar User1:(special access:)
STANDARD_RIGHTS_ALL
DELETE
READ_CONTROL
WRITE_DAC
WRITE_OWNER
SYNCHRONIZE
STANDARD_RIGHTS_REQUIRED
FILE_GENERIC_READ
FILE_READ_DATA
FILE_READ_EA
FILE_WRITE_EA
FILE_READ_ATTRIBUTES
FILE_WRITE_ATTRIBUTES
Group1:(special access:)
READ_CONTROL
SYNCHRONIZE
FILE_GENERIC_READ
FILE_READ_DATA
FILE_READ_EA
FILE_READ_ATTRIBUTES
Everyone:F
The accumulation of all the access rights granted by each individual ACE forms the effective access rights granted by the whole ACL.
When an application requests access to the file or directory, it specifies the access rights it requires. To determine if the request can be successful the DACL must be examined. If the file has no DACL, then there is no protection and all access is granted to all users. If the file has a DACL, but there are no ACEs, then access is denied to all users. Otherwise each ACE is examined to determine if the requested access is allowed.
If the SID of the ACE matches the SID of the caller (this can be the caller’s primary SID or any of its group SIDs) then the access mask of the ACE is examined. If the ACE is an access-allowed type, then all the rights in the access mask are granted. If all the rights requested are granted, then the request is successful. If the ACE is an access-denied type and any of the rights in the access mask match any of the rights in the request then the request is denied. If the end of the DACL is reached and some of the requested access rights have not been granted, then the request is denied.
Unix File Security
The file access control mechanism used in UNIX system is based on file permission bits3. Associated with each file or directory is a user ID (i.e. the owner), a group ID and a set of twelve bits known as the permission bits. Three of the bits specify the access by the file's owner, three bits specify the access allowed to users that are members of the file’s group, and the last three bits control access to everyone else (others). Each set of three permission bits consists of a read permission (r), a write permission (w), and an execute permission (x). For normal files, these permissions are straightforward. For directories, write permissions dictate whether or not users can create or delete subdirectories and files.
Besides the standard nine permission bits, there are three bits with special meaning called the setuid bit, setgid bit and “sticky” bit. The setuid and setgid permissions only apply to executable programs (binaries and/or scripts). When the setuid bit is set the program (file) is executed with the user ID of the owner of the file and NOT the user ID of the user that is accessing the file. For example, a user joe may assign the setuid permissions on one of his program files. Another user john may logon and run joe’s program. Since the setuid bit is set, the program will run as if joe has executed it. Similarly, when the setgid bit is set the program (file) is executed with the ID of the group of the file and NOT the group ID of the user that is accessing the file. The sticky bit is usually reserved for use with directories. When this bit is set, files or subdirectories in the directory can only be deleted by the owner of the file or subdirectory. When this bit is not set, anyone with write permission on the directory can remove files or subdirectories. This is used so that users who share access to a directory cannot delete each others’ files.
You can display UNIX file permissions using the /bin/ls utility. The following example illustrates the output of the command “ls –l a.out”
-rwxr-xr-- 1 sfuuser sfugrp 342 Aug 27 00:20 a.out
In this example, the owner of the ‘a.out’ file is sfuuser and the file’s group is sfugrp. The following permissions are assigned
sfuuser has read, write, execute permissions
sfugrp has read and execute permissions
All other users have read permission
The file permissions can also be represented as a 3-digit octal number, where the first, second and third octal digits represents the owner, group and other permissions, respectively. Each digit is arrived at by adding 4 for read (r) permissions, 2 for write (w) permissions, and 1 for execute (x) permissions. 0 indicates no permissions on the file/directory. For example, the permission of “rwxr-xr--“ can be represented as “754”.
When performing an access request, the permission bits are checked in the following order:
if the UID of the file is the same as the user ID of the caller, only the owner permission bits are checked. If the required access bits are not set, then access is denied.
If the UIDs do not match, but the GID of the file matches one of the GIDs of the caller, then the group permissions are checked. If the required access bits are not set, then access is denied.
Only when the UIDs and GIDs do not match are the “other” permission bits checked.
It is important to note that in UNIX, with respect to file permissions, the “others” bits pertain to the set of users exclusive of the file owner or any users that are members of the file’s group. And similarly, the permissions given to the file’s group GID pertain to any user that is a member of that group exclusive of the file owner UID.
For example, using the above example, user sfuuser can read, write and execute a.out and any user belonging to the sfugrp group, except sfuuser, can read and execute the file and not write to it. The access permitted to any other user not sfuuser and not belonging to the group sfugrp can only read the file a.out.
Similarly, a file with permissions such as
-r--r-xrwx 1 sfuuser sfugrp 0 Sep 13 19:45 a.out1
means that sfuuser can only read the file a.out1 whereas any user belonging to the sfugrp can read and execute the file. Note that even if sfuuser belonged to the sfugrp, it wouldn’t be allowed to execute the file.
For more on permission lists and bits, see the man pages for ls(1) and chmod(1).
File Creation using Interix or NFS Server
When Interix or Server for NFS creates a file on Windows the file is assigned an owner ID and a group ID. With Interix, the file owner is obtained from the user ID of the process that creates the file. The file’s group ID is taken from the group ID of the parent directory. The Server for NFS impersonates4 the mapped user when creating (or accessing) a file (UNM maintains the mapping between UID/GID and the corresponding Windows User/Group names). The file’s owner is the SID of the mapped Windows User. The file’s group ID is the SID of the mapped Windows Group name.
When a file is created on FAT or HPFS filesystems there is no assigned owner or group because these filesystems do not support the concept of ownership. All files and directories on these filesystems are accessible by anyone and everyone. So in the UNIX environments provided by SFU, files here are always represented as having an owner and group ID with the special Windows “World SID” which is visible as the name “Everyone” (note: WorldSID and Everyone are used interchangeably in this document). 5
Files created on filesystems that support Discretionary Access Controls, such as NTFS, are normally given three ACEs: One representing the permissions for the owner, one for the group and one for “other” (ie everyone else) 6 . Depending on the nature of the UNIX permission bits, there could be as many as five ACEs. These additional ACEs are special deny-access ACEs that may be necessary when the permissions granted to “group” are more permissive than the owner permissions or when the “other” permissions are more permissive than the owner or group permissions. Examples of this will be discussed below.
Mapping Unix Permissions to Windows Permissions
When converting Unix permissions into a DACL, each grouping is converted into at least one access-allowed ACE with a total of at least three ACEs. There is an ACE with the owner SID representing the owner permissions, an ACE with the group SID representing the group permission bits and an ACE with the special builtin “World-SID” representing the “other” permission bits. In addition to these three ACEs there is also the possibility of an access-denied ACE with the owner SID and possibly an access denied ACE with the primary group SID. Creating these access-denied ACEs depends on the permission relationships between other, group and owner and will be discussed in detail below.
By default, all access-allowed ACEs will contain the following Windows access rights:
Read_Control
Read_Extended_Attributes
Read_Attributes
Synchronize
These Windows access rights are always present in all ACEs in order to provide proper UNIX file access semantics. For instance, UNIX allows all users to view the permission bits on a file. So in order for stat(2) to return successfully, it must have permission to examine the file’s DACL, the file’s attributes (i.e. file size, file’s attribute bits, time stamps) and the file’s extended attributes (which is where Interix stores the setuid and setgid bits).
There are some additional Windows access rights that are always set in the access-allowed ACE for the file’s owner. This is also necessary in order to support the proper UNIX file access semantics. These access rights are:
Delete |
allows the owner to delete the file |
Write_DAC |
allows the ACEs in the DACL to be modified (eg. chmod(2) ) |
Write_Owner |
necessary for chown(2) |
Write_ExtendedAttributes |
necessary for the implementation of setuid and setgid bits |
Write_Attributes |
necessary to modify file timestamps (eg. utimes(2)) |
Additionally, if the UNIX read permission bit is set, then the Windows File_Read access right is added to the ACE. When enabled on directories, this allows them to be searched. When enabled on files, it allows the data to be viewed. If the UNIX execute permission bit is set, then the Windows File_Execute access right is added to the ACE. On directories this enables the directory to be traversed. On files it allows the file to be executed.
If the UNIX write permission bit is set then the following Windows access rights are added:
Write Data |
files – allows file to be written directories – allows new objects to be added. |
Write_Attributes |
allows file attributes to be modified (attributes like timestamps) |
Append_Data |
files - allows open(O_APPEND) |
Delete_Child |
on a directory permits sub-files and sub-directories to be deleted regardless of the access rights granted in the DACL of the sub-file |
Notice how Windows has four separate access rights to UNIX’s single “write” permission. In UNIX, the write permission bit on a directory permits both the creation and removal of new files or sub-directories in the directory. On Windows, the Write_Data access right controls the creation of new sub-files and the Delete_Child access right controls the deletion. The Delete_Child access right is not always present in all ACEs. In the case where the UNIX sticky-bit is enabled, the Delete_Child bit will be set only in the file owner ACE and no other ACEs. This will permit only the directory owner to remove any files or sub-directories from this directory regardless of the ownership on these sub-files. Other users will be allowed to delete files or sub-directories only if they are granted the Delete access right in an ACE of the file or sub-directory itself.
An example of how ACEs are created and how the default Windows access rights are set is shown here. We create a file called “foobar” which will have an owner of “User1” and group of “Group1. Then we change the permissions using the chmod(1) utility such that the file has no UNIX permissions. Then we display the Windows DACL using a special program called “lsacl” which displays the ACEs and the access rights in each ACE.
$ chmod 000 foobar
$ lsacl -ev foobar
User1 ALLOWED
Delete
Read_Control
Write_Dac
Write_Owner
Synchronize
Read_ExtendedAttributes
Write_ExtendedAttributes
Read_Attributes
Write_Attributes
Group1 ALLOWED
Read_Control
Synchronize
Read_ExtendedAttributes
Read_Attributes
+Everyone ALLOWED
Read_Control
Synchronize
Read_ExtendedAttributes
Read_Attributes
There are situations where one or two access-denied ACEs must be added to the DACL.. If you recall, the UNIX file access algorithm makes a distinction between owner, group and other such that each is unique and the ID used in an access request can only match one of them. However, the Windows file access algorithm makes no such distinction while scanning the DACL. If the ID in the request is granted permission in any of the access-allowed ACEs then the request is permitted. This is a problem when the owner permissions are specified to be more restrictive than say the group or the other permissions (eg. when a “chmod 577 foobar” is executed) So, to support UNIX semantics we must examine the permissions granted to Everyone and if they are more permissive than those in the group permissions then a special access-denied ACE must be created for the group. And similarly, if either the group or other permissions are more permissive than the owner permissions, then an access-denied ACE must be created for the owner.
Using the same example as before (a file called foobar, with owner User1 and group Group1) and change its permissions to “r-xrwxr-x” (i.e.. “chmod 575 foobar”). Since the group’s permissions allow “write” access but the owner permissions do not, an access denied ACE must be created for the owner that explicitly denies “write” access
$ chmod 575 foobar
$ lsacl -ev foobar
User1 ALLOWED
Delete
Read_Control
Write_Dac
Write_Owner
Synchronize
Read
Execute
Read_ExtendedAttributes
Write_ExtendedAttributes
Read_Attributes
Write_Attributes
User1 DENIED
Write
Append
Delete_Child
Group1 ALLOWED
Read_Control
Synchronize
Read
Write
Append
Execute
Delete_Child
Read_ExtendedAttributes
Read_Attributes
Write_Attributes
+Everyone ALLOWED
Read_Control
Synchronize
Read
Execute
Read_ExtendedAttributes
Read_Attributes
Similarly, if the permissions granted to “other” is more permissive than those granted to the group ACE then an access-denied ACE is created for the group. As is shown by:
$ chmod 757 foobar
$ lsacl -ev foobar
User1 ALLOWED
Delete
Read_Control
Write_Dac
Write_Owner
Synchronize
Read
Write
Append
Execute
Delete_Child
Read_ExtendedAttributes
Write_ExtendedAttributes
Read_Attributes
Write_Attributes
Group1 ALLOWED
Read_Control
Synchronize
Read
Execute
Read_ExtendedAttributes
Read_Attributes
Group1 DENIED
Write
Append
Delete_Child
Write_Attributes
+Everyone ALLOWED
Read_Control
Synchronize
Read
Write
Append
Execute
Delete_Child
Read_ExtendedAttributes
Read_Attributes
Write_Attributes
In the UNIX environment, the chmod(1) utility is used to modify the permission bits. This utility is just built upon the chmod(2) system call. This interface only manipulates the nine file permission bits and there is no method in Interix for manipulating the DACL or individual ACE’s. Thus, changing the permissions using chmod(1) or chmod(2) will cause a new DACL to be created on the file. Any pre-existing DACL on the file will not be re-used or preserved.. This is true for any file or directory. This is very important to remember when using both Windows utilities and UNIX environment applications on the same files.
Another special case to note is with respect to Windows special inheritance ACEs. A directory may have a DACL that contains inheritance ACEs. These ACEs are used to automatically propagate access rights to its children files and subdirectories. For Interix, any DACLs it creates will not contain any inheritance ACEs nor will it honor the inheritance ACEs that may be present on the parent directory. By default, Server for NFS behaves the same, however, there is a special registry value called KeepInheritance. 7 When set to the value of 1, this will propagate inheritable ACEs to files and subdirectories on NFS shares.
Also remember that in Windows, the file owner user ID does not have to be a user account (user account SID) as it is on UNIX systems. The owner ID could be a group account SID. In this case, even if the group and owner are the same SID, there will still be three ACEs. Two of the ACEs will have same SID. For example:
$ chown Group1 foobar
$ chmod 444 foobar
$ lsacl -ev foobar
Group1 ALLOWED
Delete
Read_Control
Write_Dac
Write_Owner
Synchronize
Read
Read_ExtendedAttributes
Write_ExtendedAttributes
Read_Attributes
Write_Attributes
Group1 ALLOWED
Read_Control
Synchronize
Read
Read_ExtendedAttributes
Read_Attributes
+Everyone ALLOWED
Read_Control
Synchronize
Read
Read_ExtendedAttributes
Read_Attribute
What about the case where both owner and group are the same SID and a chmod(1) request is made where the owner and the group permission bits are different?. Like in the case of “chmod 644 foobar”. In this case, the most restrictive permissions are chosen and assigned to both ACEs. For example:
$ chmod 644 foobar chmod: Warning: foobar: mode requested = 0644, actual mode = 0444
The Interix chmod(1) utility displays a warning message because it detects that the actual permissions set on the file are different from the request. This allows the user to note that the user’s intentions were not explicitly honored.
Windows To UNIX Mapping
In Windows, file access permission is controlled by the DACL associated with each file. This DACL can specify access rights to many different users and/or groups. But in a UNIX system environment, there are only three classes of users and only three permission bits for each class.. So when a UNIX application requests file permission information, a mapping from the DACL to these nine permission bits must be performed.
This mapping starts by searching through all the ACEs in the DACL looking for the access-allowed and access-denied ACEs and then examining only the ACEs that contain either the file’s owner SID, the file’s group SID or one of the WorldSID or the AuthenticatedUsers-SIDs.
For each of these selected ACEs, the access rights in the ACE are collected and saved into one or more of three different collections: the “owner” collection, the “group” collection and the “other” collection. These collections correspond to the three UNIX file permission classes and are used at the end when mapping access rights into permission bits. Each of these collections contains a set of granted rights and a set of denied rights to maintain the distinctions between the two different types of ACEs. When an access-denied ACE is found, the access rights are added to the set of denied rights only if the access right is not already present in the set of granted rights. For an access-allowed ACE, the access rights are added to the set of granted rights only if this access right is not already present in the set of denied rights. Note that the order of ACEs in the DACL is important because it is the first occurrence of the access right that determines whether the effective resultant access right is allowed or denied.
The access rights from an ACE with a WorldSID or AuthenticatedUsers8 SID are put into all three collections. That’s because the access rights granted to these SIDs applies to all possible users and thus applies to all three classes. The access rights from the file’s owner SID are saved into the “owner” collection and the access rights from the file’s group SID are saved into the “group” collection. Note that if the file owner and file group SIDs are the same, then the access rights are saved in both the owner” and “group” collections.
Once all the ACEs have been scanned, then the set of granted rights in each of these collections are used to set the nine UNIX file permission bits.
The complete algorithm operates like this:
For each of the ACEs in the file’s DACL,
Ignore the ACE if it is not an access-denied or access-allowed type.
If the ACE contains the Authenticated Users SID or the World SID then add the allowed or denied access right bits into the “owner”, “group” and “other” collections.
If this is an access-denied ACE, then add each access right to the set of denied rights in each collection but only if the access right is not already present in the set of granted rights in that collection. Similarly If this is an access-allowed ACE, then add each access right to the set of granted rights in each collection but only if the access right is not already present in the set of denied rights in that collection.
If the ACE contains the file’s group SID, then save the access rights in the “group” collection as appropriate in the corresponding set of granted or denied rights (as described above).
3If the ACE contains the file’s owner SID, then save the access rights in the “owner” collection as appropriate in the corresponding set of granted or denied rights (as described above).
If the ACE contains any other SID and is an access-allowed ACE, then a flag is set and all the access rights are saved in a special collection. This step is not directly relevant to the Windows to UNIX permissions translation process but it is important in two other ways:
First, the flag is remembered and is returned with the data from the stat(2) system call. This is the S_ADDACE flag in the stat->st_info member field. An example of how this is used can be seen in the output from the ls(1) utility. When printing out the long descriptive listing, it will display a “+” character appended to the permission bits to indicate that the file contains additional access control information that is not representable by the nine UNIX permission bits.
Second, the special collection of additional access rights bits is used internally in the Interix subsystem when performing security checks on setuid and setgid executable files. If any of the WRITE_DAC, FILE_WRITE_DATA or FILE_WRITE_EA access rights are granted then neither Interix nor the Server for NFS will allow this setuid or setgid file to be executed.
Once all the granted Windows access right bits have been collected, then the UNIX permission bits are assembled. For each class, if the Read_Data bit is granted, then the corresponding “r” permission bit is set. If both the Write_Data and Append_Data access rights are granted then the “w” permission bit is set. And finally, if the Execute access right is granted, then the “x” permission bit is set.
For More Information
For additional information on Services for UNIX version 3.0, check out the latest information at: Windows Services for UNIX Home (www.microsoft.com/windows/sfu), and on the SFU Newsgroup (www.microsoft.com/windows/sfu/support/xnews).
Before You Call for Support
Please keep in mind that Microsoft does not support these white papers or walkthroughs. The purpose of the white papers and walkthroughs is to facilitate your initial evaluation of the Microsoft Windows Services for UNIX features. For this reason, Microsoft cannot respond to questions you might have regarding specific steps and instructions.
Reporting Problems
Problems with Microsoft Windows Services for UNIX should be reported by way of the appropriate bug reporting channel and alias. Please make sure to adequately describe the problem so that the testers and developers can reproduce it and fix it. Refer to the Release Notes included on the Windows Services for UNIX distribution media for some of the known issues
Appendix
Access to a file is controlled by the Discretionary Access Control List (DACL) associated with the file. The DACL consists or zero or more Access Control Entries (ACLs) which specify the accounts that can access the file and specify the type of access allowed. The following are the names and the explanations for the various flags and access rights that can be associated with Access Control Entries (ACE).
Table 1 ACE flags - Special Inheritance rules
(OI) OBJECT_INHERIT_ACE |
This ACE is inherited by any new files. Non-container child objects inherit the ACE as an effective ACE. For child objects that are containers, the Ace is inherited as an inherit-only ACE unless the NO_PROPOGATE_INHERIT_ACE bit is also set. |
(IO) INHERIT_ONLY_ACE |
This ACE is only used for inheritance purposes. It indicates an inherit-only ACE that doesn’t control access to the object that it is attached to. |
(CI) CONTAINER_INHERIT_ACE |
This ACE is inherited by new sub-directories. Child objects, such as directories, inherit the ACE as an effective ACE. The inherited ACE is Inheritable unless the NO_PROPOGATE_INHERIT_ACE bit is also set. |
Table 2 Windows Access rights in an ACE
(D) DELETE |
Permission to delete this file. |
(RC) READ_CONTROL |
Permission to examine the DACL, time stamps, ownership information and other file attribute data. |
(P) WRITE_DAC |
Permission to change the DACL. |
(O) WRITE_OWNER |
Permission to take ownership. |
(S) SYNCHRONIZE |
The right to use the object for synchronization. This enables a thread to wait until the object is in the signaled state. Some object types do not support this access right. |
(R) FILE_READ_DATA |
permission to read file data or allowed to list directory entries. |
(W) FILE_WRITE_DATA |
Files: permission to write file data |
(A) FILE_APPEND_DATA |
Files: permission to write data to end of file |
(E) FILE_EXECUTE |
Files: permission to execute the file |
(DC) DELETE_CHILD |
Permission to delete directory entries. |
(RA) FILE_READ_ATTRIBUTES |
Permission to read object’s attributes. |
(WA) FILE_WRITE_ATTRIBUTES |
Permission to write object’s attributes. |
(REA) FILE_READ_EA |
Permission to read object’s extended attributes. |
(WEA) FILE_WRITE_EA |
Permission to write object’s extended attributes. |
Table 3 Standard Access Right Sets used by Windows programs
READ |
Equivalent to RC, S, R, E, REA, RA or GR,GE |
CHANGE |
Equivalent to D, RC, S, R, W, A, E, REA, WEA, RA, WA |
FULLCONTROL |
Equivalent to D, RC, P, O, S, R, W, A, E, DC, REA, WEA, RA, WA |
A pseudo-algorithm that converts Windows permissions to UNIX permissions.
…
…
permission_set owner, group, other, special ;
boolean addace_flag ;
/* Initialize the permission sets */
owner = group = other = special = NULL ;
addace_flag = FALSE ;
…
…
process_dacl()
{
/* Process every ACE in a DACL */
while ( DACL contains one or more ACE’s )
{
if ( ( type of ACE == access_allowed ) OR
( type of ACE == access_denied ) )
{
switch ( SID contained in the ACE )
{
case AuthenticatedUsers SID:
case World SID:
update_permission ( type of ACE, rights, owner );
update_permission ( type of ACE, rights, group );
update_permission ( type of ACE, rights, other );
break;
case file’s owner SID:
update_permission (type of ACE, rights, owner );
break ;
case file’s group SID:
update_permission (type of ACE, rights, group );
break ;
case file’s other SID:
update_permission (type of ACE, rights, other );
break ;
default:
if ( type of ACE is access_allowed )
{
addace_flag = TRUE ;
update_permission ( type of ACE, rights,
special );
}
} /* End of switch */
} /* End of if statement */
} /* End of while */
}
…
…
update_permission (type, access_right, bucket)
{
if ( type == access_allowed )
{
if ( denied group of the bucket does not contain access_right )
{
Add access_right to the allowed group of the bucket
}
}
else
if ( type == access_denied )
{
if ( allowed group of the bucket does not contain access_right )
{
Add access_right to the allowed group of the bucket
}
}
}
…
…
print_unix_permissions(bucket)
{
if (bucket contains File_Read ACE )
{
print (“r”)
}
else
{
print (“-”)
}
if (bucket contains File_Write and File_Append ACE )
{
print (“w”)
}
else
{
print (“-”)
}
if (bucket contains FILE_EXECUTE ACE )
{
print (“x”)
}
else
{
print (“-”)
}
}
list_unix_permissions()
{
process_dacl() ;
print_unix_permissions(owner)
print_unix_permissions(group)
print_unix_permissions(other)
}
…
…
1 "UNIX is a registered trademark of The Open Group in the United States and other countries”
2 LSA is the Local Security Authentication service
3 The UNIX file permissions are clearly described in the various POSIX standard documents such as ISO/IEC 9945-1 1990.
4 Impersonation is the ability of a thread to execute in a security context that is different from the context of the process that owns the thread.
5 The Everyone group is the Windows NT special builtin identifier known as the “World SID” which is S-1-1-0. In Interix, this ID is numerically -0x10100 or 65792
6 There is a special Windows built-in group account called the World SID which is used to represent “everyone else”
7 The full registry pathname is: HKLM\Software\Microsoft\Server for NFS\CurrentVersion\Mapping\KeepInheritance
8 The Authenticated Users group is a group of users whose membership is controlled by the operating system or the domain. It is the same as the Everyone group, except that it does not contain anonymous users or guests. Unlike the Everyone group in Windows NT 4.0, the Authenticated Users group is not used to assign permissions