ACLs on Windows (for pre-StorNext 5 release 5.4.0 Systems)

Note: The information in this section is applicable for releases up to StorNext 5 release 5.3.x (in other words, prior to StorNext 5 release 5.4.0). Refer to StorNext Security for the new information, beginning with StorNext 5 release 5.4.0.

Each mapped drive, file, or folder on Windows contains a Windows Security Descriptor. This descriptor contains the owner, primary group, DACLs, and SACLs. Windows uses the Security Descriptor to control access to each object. Windows Administrators and Users typically use Windows Explorer to view, change, and create ACLs on files. This is done in Explorer by first selecting the file or folder, displaying its properties, and then clicking on the Security tab.

Each file/folder can have zero or more ACLs that specify how a user or group can access or not access the file or folder. The possible controls in each ACE are:

Folders

Files

Full control (all of the following)

Full control (all of the following)

Traverse Folder

Execute File

List Folder

Read Data

Read Attributes

Read Attributes

Read Extended Attributes

Read Extended Attributes

Create Files

Write Data

Create Folders

Append Data

Write Attributes

Write Attributes

Write Extended Attributes

Write Extended Attributes

Delete Subfolders and Files

 

Delete

Delete

Read Permissions

Read Permissions

Change Permissions

Change Permissions

Take Ownership

Take Ownership

Each Item can be selected as: Allow, Deny, or not selected. If Full Control is selected as Allow or Deny, all the other attributes are set to either Allow or Deny.

In addition, each ACE on Windows is indicated to apply as follows:

  • Folder
    • This folder only
    • This folder, subfolders, and files
    • This folder and subfolders
    • This folder and files
    • Subfolder and files only
    • Subfolder only
    • Files only
  • File
    • This object only

An individual object can also be set to disallow or allow inheritable ACLs from a parent, parent's parent, etc.

A folder can be created and it can be marked such that all of its ACLs will pass to any children. This process is called propagation. Individual ACLs on a folder can be propagated as indicated in the above list. File and sub-folders of a folder can have all or some of the “inherited” ACLs removed.

The propagation/inheritance information is contained in the Windows Security Descriptor. Users and administrators on Windows platforms use this capability extensively.

ACEs are ordered in an ACL. Explicit ACEs come first. An explicit ACE is one that is not inherited. Explicit ACEs which deny come before explicit ACEs which allow. Inherited ACEs are ordered such that the closer the parent, the sooner they appear. Each level of inherited ACEs contain deny before allow.

All file and folder access is determined by matching a user and group to the DACL of the object being accessed. The SACL is not used to perform the access check. The ACEs in the DACL are compared in order with the accessing user and group for the requesting access mode. If a “deny ACE” matches, access is denied. If an “allow ACE” matches all requested access bits, access is allowed. It is possible to have a “deny ACE” inherited after an “allow ACE” which will not take effect. This can happen because explicit ACEs take precedence as do inherited ACEs from a closer parent. See the examples in the Microsoft document "How Security Descriptors and Access Control Lists Work".

When a Windows user creates a file on SNFS the Security Descriptor (SD) is kept as an attribute of the file object. The SD contains a primary SID, a group SID and a list of discrete ACLS (also know as the DACL). The SNFS file object also contains the Unix UID, GID and permissions fields.

If the file system configuration global UnixFabricationOnWindows is set to true, the Unix UID and GID values are populated based on the GUIDs of the Active Directory records.

If UnixFabricationOnWindows is set to false, the Unix UID and GID values are populated from the RFC2307 mappings in Active Directory. If the SID for the logged in user does not have a UID configured in Active Directory, a newly created file will receive a UID equal to the value of the file system configuration setting UnixNobodyUidOnWindows. If the SID for the logged in user does not have a GID configured in Active Directory, a newly created file will receive a GID equal to the value of the file system configuration setting UnixNobodyGidOnWindows.

The UNIX modes are controlled by the following file system configuration parameters:

  • UnixDirectoryCreationModeOnWindowsDefault
  • UnixFileCreationModeOnWindowsDefault

StorNext allows one set of values for all users of each file system.

Note: The value of the file’s Winodws read-only attribute does not affect the file’s Unix mode.

Note: Administrators can manually change these values in the file system configuration file on the server or use the Windows or Web GUI.

For additional information, refer to the snfs_config(5) man-page or the following sections in the Windows Help.

  • User ID Mapping Overview
  • Windows Active Directory Config
  • Apple/XSAN Fabricated ID’s
  • Unix Permissions Background