Traditional UNIX permissions and NFSv4 Access Control Lists
Traditional UNIX permissions
Linux is a multi-user OS that is based on the Unix concepts of file ownership and permissions to provide security at the file system level. Each file is owned by a single user, a single group, and has its own access permissions. The traditional UNIX file system object permission model defines three permission classes called owner, group, and world:
There are three basic permissions defined as read (r), write (w), and execute (x) associated to each of these classes
To see a file's permissions settings, the -l option for the ls command provides information that includes permissions in the first column.
drwxr-xr-x 3 edington hpc 423 Nov 4 2011 test_data
-rw-r--r-- 1 edington hpc 28 Nov 6 2015 TESTFILE
-rwxr-xr-x 3 edington hpc 423 Nov 4 2011 myscript.sh
A “d” at the beginning of a line indicates the file is a directory, a “-” at the beginning of a line indicates that it is a regular file. The rest of the permissions block is broken up into three-character groups, corresponding in order to owner's read, write, and execute; group's read, write, and execute; and world's read, write, and execute. A dash in any position indicates that the relevant entity category does not have that permission.
You can see the group memberships for a user with the id command:
uid=1020(edington) gid=3010(hpc) groups=3010(hpc),4(adm),2006(database)
Access Control Lists
Traditional UNIX permissions are very limited in the access they can provide. UNIX permissions can only be set for the owner, one group and everyone else (other). Access Control Lists (ACLs) are more recent in origin and are universally used on Microsoft Windows based file systems. They are complex but capable of more detailed fine-tuning of permissions than the traditional Unix permissions. ACLs can assign permissions to the owner, the group and to multiple specific users and groups of users.
On Unix and Linux based systems POSIX ACLs are the standard but other variants exist such as NFSv4 ACLs which work slightly differently. NFSv4 ACLs provide finer granularity than typical POSIX read/write/execute permissions and are similar to SAMBA (or CIFS) ACLs. We are recommending NFSv4 ACLs because the syntax is sane, recursion is supported and it is recommended for IBM SAMBA.
Traditional NFSv4 ACL syntax
An ACL is a list of permissions associated with a file or directory and consists of one or more Access Control Entries (ACEs). An ACE is an individual entry in an access control list, and describes the permissions for an individual user or group of users. An ACL can have zero or more ACEs.
A single NFSv4 ACE is written as an ace_spec, which is a colon-delimited 4-field string in the following format:
All parts are required for every operation though the [flags] section may be empty. To get a list of what all the mask bits mean type "nfs4_getfacl" or read the nfs4_acl(5) manpage http://man7.org/linux/man-pages/man5/nfs4_acl.5.html. Here are the most common options for an ACE.
A Allow - allow principal to perform actions requiring permissions.
GROUP FLAG - can be used in any ACE
g group - indicates that principal represents a group instead of a user.
INHERITANCE FLAGS - can only be used in a directory ACE Don’t use these unless you know exactly what you are doing. They are complicated.
fdi — These flags collectively indicate that the ACE is to be inherited. If set, any file created below the directory will have the given ACE, but without the inheritance flags. Additionally, any directory created below one with these flags will have the ACE, and will also have a second ACE with the inheritance flags. Inheritance flags are recursive. Check this...I think this only works if the ACL is put on the directory before any files or subdirectories are created.
'r' read-data / list-directory
'w' write-data / create-file
'a' append-data / create-subdirectory
'D' delete-child (directories only)
Examples of NFSv4 ACL commands
To read an ACL, use nfs4_getfacl on a file in a nfsv4-mounted directory use nfs4_getfacl.
Need more local examples here
To modify an acl, use nfs4_getfacl on a file in a nfsv4-mounted directory:
nfs4_setfacl -e /mnt/nfsv4/my-file.txt
which will allow you to edit the acl in a text editor; edit the acl and save the result, and the modified acl will be set on the file when you exit. Alternatively, you can give the ACEs in a file
More local examples here.
Where to set NFSv4 ACLs
hpc-acl01.mskcc.org is a VM with NFSv4 mounts of GPFS file systems. If you would like to manage ACLs please contact us and we can provide access and a NFSv4 mount of your data.
The users and groups for the ACLs come from HPC LDAP. HPC is responsible for maintaining them at this time.
Moving data with NFSv4 ACLs
User space utilities cp and tar are capable of transferring the NFSv4 ACLs using extended attributes. The CentOS7 default rsync version 3.1.2 is not. We do not have this rsync version on any of our systems at this time and ACLs will not be backed up. Rsync version 3.1.3 has added filter options that will allow this to work in future when we upgrade to RHEL 8 or CentOS 8.
All HPC GPFS file systems support NFSv4 ACLs. Isilon /ifs and local directories such as /scratch do not. If you copy a file with --preserve=xattr to another filesystem that does not support NFFv4 ACLs they will be mapped to POSIX ACLs. if the original ACL is representable as a POSIX ACL, then the ACL returned should represent equivalent permissions to the one set. If not, then the ACL returned should have permissions that are stricter than those requested. See the getacl and setacl man pages for more documentation.
The ls -l command does not show a “+” at the end of the permissions when a file has an attached NFSv4 ACL. https://bugzilla.redhat.com/show_bug.cgi?id=1269951
ACLs should only be set on an NFSv4 mount point or from a SAMBA mount on a Windows (Mac?)
Do not use ACL inheritance. Recursion works for NFSv4 ACLS, use that.
NFSv4 ACLs in GPFS
GPFS has support for NFSv4 ACLs but the syntax is different. While traditional NFSv4 ACLs display one entry per line, each GPFS representation of a NFSv4 ACL entry is three lines. The fields are in a completely different order and they include special key words. This is to confuse everyone. While you can view ACLs in GPFS we do not recommend that you set them using GPFS commands. Read on if you want to understand how to view NFSv4 ACLs in GPFS. Here is the description of NFSv4 ACLs from the spectrum scale documentation at https://www.ibm.com/support/knowledgecenter/STXKQY_5.0.4/com.ibm.spectrum.scale.v5r04.doc/bl1adm_nfsv4syn.htm
The first line has several parts separated by colons (':').
As in traditional ACLs, users and groups are identified by specifying the type and name. For example, group:staff or user:bin. NFS V4 provides for a set of special names that are not associated with a specific local UID or GID. These special names are identified with the keyword special followed by the NFS V4 name. These names are recognized by the fact that they end with the character '@'. For example, special:owner@ refers to the owner of the file, special:group@ the owning group, and special:everyone@ applies to all users.
The next two lines provide a list of the available access permissions that may be allowed or denied, based on the ACL type specified on the first line. A permission is selected using an 'X'. Permissions that are not specified by the entry should be left marked with '-' (minus sign).
These are examples of NFS V4 ACLs.
Using mmsetfacl is potentially damaging as they will overwrite the posix permissions and have no append or delete capability. --check this.