Enable ACLs on a StorNext MDC (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.

ACLs were introduced on Mac OS 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.

Enable ACLs on a Linux MDC

  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 Advanced Parameters to expand the section.
  4. On the Features tab, click Enforce ACLS.
  5. Click Apply to save the file system changes.

Enable ACLs on a Windows MDC

  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 Mac OS 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 Mac OS 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 Mac OS 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 subdirectories created in this directory.
  3. limit_inherit: After propagating this ACE to a new subdirectory, do not let its subdirectories 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

Mac OS 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 Mac OS 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. Window's has a check box to cause some of this action when creating an ACE. On Mac OS 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.