Display and Modification of File Permissions

On non-Windows systems, Unix permission bits and file ownership are displayed using the ls command and modified using the chmod, chown, and chgrp commands.

On native Window StorNext clients, Unix permission bits can be displayed and modified using the StorNext cvstat command from a DOS shell. When using the unixpermbits security model with either mdc or ldap identity mapping, Unix permission bits may also be displayed and modified using the Windows Security tab.

Note: The Windows Security tab is accessed in Windows Explorer by right-clicking on a file or folder, selecting Properties and navigating to the Security tab.

In this case, StorNext synthesizes an ACL based on the Unix permission bits. The following example illustrates Unix permissions as displayed from a Linux system.

# ls -lt testfile

-rw-r--r-- 1 jdoe domain users 0 Aug  7 16:23 testfile

Figure 1 illustrates the same Unix permissions displayed as a synthesized ACL in Windows Explorer.

Figure 1: Unix permissions Displayed as a Synthesized ACL in Windows Explorer

When using the unixpermbits security model, the Windows security tab displays three Access Control Entries (ACEs). 

  • One for the owner of the file
  • One for the group
  • One for Everyone

The displayed ACE permissions correspond other Unix permissions on the file. In the figure, the Unix mode on the file is 0644 which means that the owner of the file (jdoe) has READ and WRITE permission for the file, the group (domain users) has READ permission, and finally Everyone has READ permission which corresponds to the unix permission bits for “others”.

Note: Permissions can be modified by clicking the Edit button. Also, it is possible to change the ownership of the file by clicking the Advanced button and navigating to the Owner tab. However, this operation may only be performed by the Domain Administrator.

Note: If the UID cannot be uniquely mapped to a Windows user, the Security tab displays the owner as CREATOR OWNER. In this case, modifying permissions from Explorer is not allowed. Similarly, if the GID of the file cannot be mapped to a Windows group, the Security tab displays the group as CREATOR GROUP.

Table 1 provides tools (which vary by platform and protocol) used for displaying and modifying ACLs.

Table 1: Tools Used for Displaying and Modifiying ACLs
 

Display ACLs

Modify ACLs

Windows

Explorer security tab

icacls

cacls

Explorer security tab

icacls

cacls

Mac OS

ls -le

chmod +a

chmod -a

chmod =a

etc.

Linux and Unix Native StorNext Clients

snacl -l

snacl +a

snacl -a

snacl =a

etc.

Linux NFSv4 clients¹

nfs4_getfacl

nfs4_editfacl

nfs4_setfacl

Solaris NFSv4 clients¹

ls -lV

chmod A+spec

chmod A-spec

chmod A=spec

etc.

AIX NFSv4 clients¹

aclget

acledit

aclput

HP-UX NFSv4 clients²

N/A

N/A

¹Display and modification of ACLs over NFS is only supported when the NFS server is running on a StorNext appliance.
²While HP-UX NFS clients cannot display or modify ACLs, they are still enforced and inheritance is still in effect.

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 the Apple chmod(1) man-page or the StorNext snacl(1) man-page for additional details.