Permission Enforcement Details

Permission enforcement varies based on the platform and StorNext configuration parameters.

File Permission Enforcement on Linux, Unix, and Mac OS Environments

When using the unixpermbits or legacy Security Model, Linux and Unix systems use the standard Posix permission bit model. When ACLs are enabled for all systems by using the acl Security Model or on Mac OS systems using the encorceAcls file system configuration variable, these systems will first check whether the given file or directory contains an Access Control Entry (ACE) that applies to the user and operation being performed. If so, the ACE will be used to determine access. Otherwise, the Unix permission bits are used.

Note: While Unix permissions have only 3 bits (READ/WRITE/EXECUTE), the ACEs contained in an ACL may contain up to 14 bits. Not all of the ACE permission flags have meaning outside of Windows, but many do, depending on the file operation being performed. Table 1 describes how these flags are used for common file system operations on Linux, Unix, and Mac OS platforms.

Table 1: Effect of ACE Permission Flags on Non-Windows Platforms when ACLs are Enabled

Permission Flag	DENY on Directory	ALLOW on Directory	Deny on FILE	ALLOW on FILE
Read Data/List Folders	Disallows readdir(3)	Allows readdir(3)	Disallows open(2) for READ	Allows open(2) for READ
Write Data/Create Files	Disallows creat(2) / open(2) that results in a new file	Disallows creat(2) / open(2) that results in a new file	Disallows open(2) for WRITE	Allows open(2) for WRITE
Append Data/Create Subfolders	Disallows mkdir(2)	Allows mkdir(2)	Disallows open(2) for APPEND	Allows open(2) for APPEND
Read Extended Attributes	Disallows getxattr(2)	Allows getxattr(2)	Disallows getxattr(2)	Allows getxattr(2)
Write Extended Attributes	Disallows setxattr(2)	Allows setxattr(2)	Disallows setxattr(2)	Allows setxattr(2)
Execute/Traverse Folders	Disallows path traversal through a directory	Allows path traversal through a directory	Denies binary/script execution	Allows binary/script execution
Delete Subfolders and Files	Disallows deletion of immediate descendant, unless target object ALLOWS delete	Allows deletion of immediate descendant	N/A	N/A
Read Attributes	Disallows stat(2)	Allows stat(2)	Disallows stat(2)	Allows stat(2)
Write Attributes	Disallows utimes(2)	Allows utimes(2)	Disallows utimes(2)	Allows utimes(2)
Read Permissions	Disallows stat(2) and displaying ACL (e.g. snacl -l)	Allows stat(2) and displaying ACL	Disallows stat(2) and displaying ACL	Allows stat(2) and displaying ACL
Write Permissions	Disallows chmod(2) and ACL modifications	Allows chmod(2) and ACL modifications	Disallows chmod(2) and ACL modifications	Allows chmod(2) and ACL modifications
Delete	Disallows rmdir(2) unless delete_child is permitted	Allows rmdir(2)	Disallows unlink(2) unless delete_child is permitted by parent	Allows unlink(2)
Change Owner	Disallows ACL modifications	no effect	Disallows ACL modifications	no effect
Synchronize	no effect	no effect	no effect	no effect

File Permission Enforcement on Native StorNext Windows Clients and Windows SMB Clients Attached to a Windows SMB Server

When using the unixpermbits Security Model, Windows systems map Unix permission bits to Windows rights as shown in Table 2.

Table 2: Windows Rights when using Unixpermbits Security Model

Unix Permission Bit	Granted Windows Rights - Regular Files	Granted Windows Rights - Folders
READ	Read Data	List Folders
	Read Extended Attributes	Read Extended Attributes
	Read Attributes	Read Attributes
	Read Permissions	Read Permissions
WRITE	Write Data	Create Files
	Append Data	Create Subfolders
	Write Extended Attributes	Write Extended Attributes
	Write Attributes	Write Attributes
	Delete	Delete
		Delete Subfolders and Files
EXECUTE	Execute	Traverse Folders

The ability to update permissions (which for ACLs would correspond to the Change Permissions right) is granted to the owner of the file or to the Domain Administrator. The ability to change file ownership (which for ACLS would correspond to the Take Ownership) is granted only to the Domain Administrator.

When ACLs are enabled, Windows systems use the ACL on a file or folder for determining access and the Unix permission bits are ignored.

ACL enforcement on Windows systems works as follows: 

The ACL on each file/folder contains zero or more ACEs that specify how a user or group can access or not access the file or folder. Each ACE specifies a principal (in other words, a user or group), the type (ALLOW or DENY), permission flags and inheritance flags. Table 3 provides the possible permission flags in each ACE.

Table 3: Possible Permission Flags in each ACE

Folders	Files
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

All file and folder access is determined by matching the accessing user and associated groups to the ACL of the object being accessed. The ACEs in the ACL are compared in order with the accessing user and groups 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.

If a file or folder does not have an ACL, because, for example, it was created on a system that didn’t support them, then on the Windows client, StorNext will automatically synthesize one based on the parent folder. If the parent does not have an ACL, StorNext searches backward all the way to the root for an ACL to use. If the Security Model is set to legacy and Windows Security is disabled, then Windows clients will not perform a security check.

File Permission Enforcement on SMB Clients Using a Samba Server Running StorNext NAS

When using the unixpermbits or legacy Security Model, SMB clients use the standard Posix permission bit model. When ACLs are enabled, these systems check to see whether given file or directory contains an ACE that applies to the user and operation being performed. If so, the ACE will be used to determine access. Otherwise, the Unix permission bits are used.

Note: While this sounds similar to how file permissions are enforced for Linux, Unix, and Mac OS environment, there is a subtle difference.