Understanding Windows and UNIX file system security

Windows and UNIX both let you control access to your files and directories. The method for doing so differs greatly, however. Generally speaking, the UNIX system is simpler and more limited, while Windows file security is considerably more complex and flexible.

In UNIX, the directory entry for each file or directory includes a bitmap of 12 bits, known as file-mode bits. Of these, three bits control access by the file's owner, three bits control access by the owner's primary group, and three control access by everyone else. For more information about how these bits are interpreted, see chmod(1).

In Windows, files and directories on NTFS partitions are protected by a discretionary access control list (DACL) consisting of one or more access control entries (ACEs). Each entry assigns or denies permissions to a user or group; unlike with UNIX, however, the number of permissions that can be granted or denied is quite extensive, and provides for a much finer degree of control over the access allowed to the user or group. In addition, ACEs can be added to the DACL for any number of users or groups, allowing the file's owner complete control over who can and cannot access the file. For more information about how Windows file-system security works, see Windows Help.

Windows Services for UNIX gives Windows users the ability to access files on UNIX servers using the Network File System (NFS) protocol, and likewise gives users of UNIX computers the ability to access files on Windows servers running Server for NFS. In addition, Interix provides a UNIX-like environment for Windows users, giving Interix users the ability to access and manage files on the Windows computer using UNIX utilities. Because the same file, whether it is located on a Windows or a UNIX computer, can be accessed by both Windows and UNIX users, it is important to understand how UNIX file security and Windows file security interact through Windows Services for UNIX. The remainder of this topic describes how Windows permissions are represented using UNIX file-mode bits, and how UNIX file-mode bits are represented by Windows DACLs.

Representing Windows permissions using UNIX file modes

A UNIX client examining the security on a file shared through Server for NFS or an Interix user using UNIX utilities to work with files on an NTFS partition cannot see the complete protection provided the file by Windows file security. This is because the UNIX file-security system is much simpler and so is unable to represent the depth of access control provided by the ACEs in the files DACL. Instead, Windows Services for UNIX presents a simplified view of the DACL that is consistent with UNIX conventions.

The following describes how this simplified view is constructed:

• ACEs that affect the file's owner, Everyone, and Authenticated Users are used to determine the file-mode bits that are set for the owner. Consistent with Windows security, the most permissive entry is used unless an access mode is explicitly denied. For example, if the owner is not given (but also not denied) write permission for the file, but Everyone is granted write permission, then Windows Services for UNIX will show the write-access bit set for the owner. On the other hand, if Everyone is denied write access, then the write-access bit will not be set for the owner. Unlike in Windows, groups to which the owner belongs are not used to determine the owner's permissions.
• ACEs that affect the owner's primary group, Everyone, and Authenticated Users are used to determine the file-mode bits that are set for the owner's UNIX group, again using the most permissive entry unless an access mode is explicitly denied. Other groups (including parent groups of the owner's primary group as well as any other groups to which the owner belongs) are ignored.
• ACEs that affect Everyone and Authenticated Users are used to determine the file-mode bits for other users, again using the most permissive entry unless an access mode is explicitly denied.
• ACEs for users and groups other than those representing the file's owner, the owner's primary group, and Everyone are ignored. For example, if the owner belongs to a group that has an access permission not granted the owner, the corresponding file-mode bit is not set for owner.

Representing UNIX file modes using Windows permissions

As noted previously Windows DACLs provide a much finer level of access control that does UNIX. As a consequence, Windows Services for UNIX represents a single UNIX file-mode bit using multiple permissions in the relevant ACEs in a file's DACL. The following describes how access bits are mapped to Windows permissions:

• For owner, group, and everyone, if a file-mode bit is set, then the corresponding Windows permissions are granted. If owner is denied an access permitted to either group or everyone, then the file's owner is explicitly denied that access by Windows. If owner, group, and everyone are all denied access, the file's owner is not explicitly denied access, but is not granted access either.
• Regardless of the UNIX file-mode settings, the file's owner, primary group, and Everyone always receive permissions for Read Attributes, Read Extended Attributes, and Read Permissions for the file. In addition, the file's owner also receives permissions for Write Attributes, Write Extended Attributes, Delete, Change Permissions, and Take Ownership for the file.
• The UNIX read bit is represented in Windows as the List Folder/Read Data permission.
• The UNIX write bit is represented in Windows as the Create File/Write Data, Create Folders/Append Data, Write Attributes, and Delete Subfolders and Files permissions.
• The UNIX execute bit is represented in Windows as the Traverse Folder/Execute File permission.

Additional considerations

You should take care when using UNIX utilities such as chmod(1) to change permissions for a file stored on an NTFS partition. Doing so will overwrite the file's DACL with a DACL consisting of ACEs for the file's owner, primary group, and Everyone.

If you use UNIX utilities such as cp(1) to create a file on an NTFS partition, the file does not inherit its permissions from the folder as is typically the case when a file is created using a Windows program. Instead, permissions are applied as described above.

The setuid, setgid, and sticky file-mode bits can be set and queried on files stored on NTFS partitions.