StorNext Security (for pre-StorNext 6 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 6). Refer to StorNext Security for the new information.

There are two predominant security models in legacy file systems: POSIX and Access Control Lists (ACLs). ACLs are actually “Lists” composed of Access Control Entries. These lists may be quite simple or quite complicated, depending on the user's requirements.

The POSIX model is the older and less flexible of the 2, having just 3 main security groups:

There are 3 operation categories:

For a directory, Execute translates to the ability to change into that directory, while Read and Write control directory listings and file creation and deletion.

POSIX permissions are kept in the file's inode information and are read from the file system on Unix/Linux systems by calls to stat().

In order to know what kind of restriction to place on a file or directory, the OS first has to be able to track users and groups so it can later be matched up with its associated information in files and directories. On Windows, all users have two unique Security Identifiers (SIDs): one for their user identification and one for the groups they belong to. On Unix/Linux and macOS X, every user has a User IDentifier (UID) and that user is assigned to a group which has its own Group IDentifier (GID).

This is the model that's built into StorNext and used by all StorNext clients on all operating systems unless it's overridden by the use of ACLs.

ACLs are currently supported only on Windows and macOS X. ACLs give fine-grained control over file access and do things POSIX permissions cannot, such as allow for writes to a file while not allowing the file to be deleted. ACLs also offer the benefit of “inheritance”, which allows a directory to specify the default set of ACLs for all files created inside of it.

ACLs are kept in the Extended Attributes for a file, which is an internal data structure attached to the file's first inode that contains additional information associated with the file. Only operating systems that know to ask for the extended information with the proper key will understand these ACLs. Currently, only macOS X and Windows know to use this information.

The StorNext File System implements both the Unix POSIX model, and on its Windows clients it implements the Windows Security Reference Model (SRM) to a level compatible with Microsoft's NTFS file system. Quantum attempts to marry the two models in a very simplistic way to allow a common user to bridge file objects between Unix and Windows. For additional information, see General Operating Guidelines and Limitations.

StorNext does not implement any of the Unix ACLs models or the NFSv4 ACLs model.

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

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

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

ACLs were introduced on macOS X 10.3 (Tiger) systems. Mac and Windows systems share equivalent ACLs implementation. ACLs must be enabled on the StorNext file system. To enable ACLs on an existing file system, perform the steps below.

  1. Using the StorNext GUI, on the Configuration menu, click File Systems.
  2. Select the file system from the table, and then click Edit....
  3. Click Configuration Parameters to expand the section.
  4. On the Features tab, click Enforce ACLS.
  5. Click Apply to save the file system changes.
  1. Stop the file system.
  2. Depending on your Windows operating system, navigate to and execute the File System Cfg (Advanced) server configuration utility.
  3. Select an existing file and click Open Existing Configuration to edit an existing configuration file.
  4. On the Global Settings tab, under XSAN Client Behavior, select the Enforce ACLs check box to enable ACLs.
  5. If a check-mark already exists in the Enforce ACLs check box, Enforce ACLs is enabled.
  6. Click OK to save the file system configuration.
  7. Click Save, and then click Yes when prompted to overwrite the file system configuration.
  8. Start the file system.

The chmod(1) and ls(1) commands have been modified to handle ACLs. There is also a library API for applications, acl(3) that allows programs to operate on ACLs.

For a detailed description of macOS X ACLs, see “Security Overview: Permissions” from Apples web sites and click on ACLs.

ACLs take precedence over regular UNIX permissions. If no ACE match is found for a user's requested access, UNIX permissions are checked. Therefore, a user may not match any ACE but still have access if UNIX permissions allow.

Each ACE on macOS X has the same 13 possible permission bits as a Windows ACE:

Directories

Files

Search Through

Execute File

List Contents

Read Data

Read Attributes

Read Attributes

Read Extended (named) Attributes

Read Extended (named) Attributes

Create Files

Write Data

Create Subdirectories

Append Data

Write Attributes

Write Attributes

Delete Subdirectories and Files

 

Delete this Directory

Delete this Directory

Read Permissions (ACL)

Read Permissions (ACL)

Change Permissions (ACL)

Change Permissions (ACL)

Take Ownership

Take Ownership

Inheritance on macOS X is similar but does vary from Windows propagation and inheritance. Each ACE applied to a directory can be “propagated” by indicating one of 4 tags:

  1. file_inherit: Propagate this ACE to files created in this directory.
  2. directory_inherit: Propagate this ACE to sub-directories created in this directory.
  3. limit_inherit: After propagating this ACE to a new subdirectory, do not let its sub-directories inherit this ACE.
  4. only_inherit: Do not apply this ACE to this directory, just to files and/or directories created below it.

The “limit_inherit” exists in Windows as a check box when creating an ACE on a folder that propagates. The mapping of the 3 remaining tags to the 7 Windows propagation pull down menu options are as follows:

Windows

macOS X

This folder only

(none)

This folder, subfolders, and files

directory_inherit, files_inherit

This folder and subfolders

directory_inherit

Subfolders and files only

files_inherit

Subfolders and files only

files_inherit, directory_inherit, only_inherit

Subfolders only

directory_inherit, only _inherit

Files only

files_inherit, only_inherit

On macOS X, propagation/inheritance is typically applied only when a file or directory is created. That is, when an object is created, its parent's list of ACEs is checked and any that apply are “inherited.” When an ACE is added to a parent directory, it is not “automatically” propagated to any existing files or directories. The Windows operating system provides a check box to cause some of this action when creating an ACE. On macOS X, the “chmod” command with the “+ai” option can be used to cause children to inherit an ACE. This can be done for large sub-trees with the chmod -R option.

Order of ACE entries is important because some ACEs might explicitly deny while others allow. Local ACEs are entries which are not inherited and by default are inserted before inherited ACEs. ACEs are checked in order for the requesting user/group and the requested access. The first ACE that denies or allows all the requested access stops permission determination. If there is a subsequent opposing deny or allow ACE, it will be ignored.

ACLs can be explicitly ordered with the chmod command which can lead to “non-canonical” ordering of ACLs. See Apple documentation for more details.