To access or not to access
© 2014 Dennis Leeuw dleeuw at made-it dot com
License: GPLv2 or later
The nfs4 tools package (nfs4_setfacl and nfs4_getfacl) uses an ACE syntax of:
type:flags:principal:permissionsThe fields can be described like this:
| RFC 3530 | nfs4_tools | Remarks | ||
|---|---|---|---|---|
| NFSv4 ACE | type | flag | permission | |
| ACL4_SUPPORT_ALLOW_ACL | A | Explicitly grants the access. | ||
| ACL4_SUPPORT_DENY_ACL | D | Explicitly denies the access. | ||
| ACL4_SUPPORT_AUDIT_ACL | U | LOG any access attempt to a file or directory. | ||
| ACL4_SUPPORT_ALARM_ACL | L | Generate a system ALARM when any access attempt is made. | ||
| ACE4_IDENTIFIER_GROUP | g | Indicates that the "who" refers to a GROUP as defined under UNIX. | ||
| ACE4_DIRECTORY_INHERIT_ACE | d | Propagate ACE to subdirectory. | ||
| ACE4_FILE_INHERIT_ACE | f | Propagate ACE to file in directory. | ||
| ACE4_INHERIT_ONLY | i | Only inherit the ACE, do not evaluate during access. | ||
| ACE4_NO_PROPAGATE_INHERIT_ACE | n | Do not propagate inheritance | ||
| ACE4_SUCCESSFUL_ACCESS_ACE_FLAG | S | Trigger an alarm/audit when principal is allowed to perform an action covered by permissions. | ||
| ACE4_FAILED_ACCESS_ACE_FLAG | F | Trigger an alarm/audit when principal is prevented from performing an action covered by permissions. | ||
| ACE4_READ_DATA | r | Permission to read the data of the file. | ||
| ACE4_LIST_DIRECTORY | r | Permission to list the contents of a directory. | ||
| ACE4_WRITE_DATA | w | Permission to modify a file's data. | ||
| ACE4_ADD_FILE | w | Permission to add a new file in a directory. | ||
| ACE4_ADD_SUBDIRECTORY | a | Permission to create a subdirectory in a directory. | ||
| ACE4_APPEND_DATA | a | The ability to modify a file's data, but only starting at EOF. | ||
| ACE4_DELETE | d | Permission to delete the file or directory. | ||
| ACE4_DELETE_CHILD | D | Permission to delete a file or directory within a directory. | ||
| ACE4_EXECUTE | x | Permission to execute a file or permission to traverse/search a directory. | ||
| ACE4_WRITE_OWNER | o | Permission to write the owner and owner_group attributes. | ||
| ACE4_READ_ACL | c | Permission to read the ACL. | ||
| ACE4_WRITE_ACL | C | Permission to write the ACL. | ||
| ACE4_READ_NAMED_ATTRS | n | Permission to read the named attributes of a file or to lookup the named attributes directory. | ||
| ACE4_WRITE_NAMED_ATTRS | N | Permission to write the named attributes of a file or to create a named attribute directory. | ||
| ACE4_READ_ATTRIBUTES | t | The ability to read basic attributes (non-ACLs) of a file. | ||
| ACE4_WRITE_ATTRIBUTES | T | The ability to write basic attributes (non-ACLs) of a file. | ||
| ACE4_SYNCHRONIZE | y | Permission to use the file object as a synchronization primitive for interprocess communication. | ||
To map the draft POSIX ACLs from GNU/Linux to the NFSv4 ACLs we used the http://tools.ietf.org/html/draft-ietf-nfsv4-acl-mapping-05.
To map the GNU/Linux POSIX ACEs to NFSv4, we need to realize that the NFSv4 tools use the following syntax:
type:flags:principal:permissionsTo write out append (A) rules we first want to figure out the flags.
Based on the description on page 3 of the IETF Draft document, groups need to get the g flag. If a default ACE rule exists on GNU/Linux it also means that the ACE should be inherited, both to files and directories. So based on the existence of a default rule we add df flags to our append rule.
If the SGID-bit is set on the directory it means we need to maintain the groupname on the directory. This is not how NFSv4 ACLs work. What we want is that the group rights are maintained on the directory and its files, thus we add fd flags to the GROUP@ ACE when the SGID-bit is set.
user:: lines are converted to OWNER@ lines, group:: lines to GROUP@ lines, and other:: lines are converted to EVERYBODY@ lines. Normal user lines are converted to user@domain lines.
Next we need to maintain the permissions as close as possible. Instead of using a mask line, for which I could not find a corresponing entry in the nfs4_setfacl man-page although a proposal was written in 2006, in NFSv4 we gonna use the effective rights as the basis for the conversion of the user and group rights to their respective NFSv4 ACEs.
That being said we can use the conversion rules described in the IETF Draft document to convert the #effective: rights into NFSv4 permission bits.