NFS4 Access Control List
AIX® also supports the NFS4 Access Control List (ACL) type.
The NFS4 ACL type implements access control as specified in the Network File System (NFS) version 4 Protocol RFC 3530. The JFS2 file system allows a maximum size of 64KB for NFS4 ACLs.
Only NFS V4 client supports NFS V4 ACLs. Both, Cachefs and Proxy do not support NFS V4 ACLs.
Textual representation of NFS4 ACL
IDENTITY ACE_TYPE ACE_MASK ACE_FLAGS
where:
IDENTITY => Has format of 'IDENTITY_type:(IDENTITY_name or IDENTITY_ID or IDENTITY_who):'
where:
IDENTITY_type => One of the following Identity type:
u : user
g : group
s : special who string (IDENTITY_who must be a special who)
IDENTITY_name => user/group name
IDENTITY_ID => user/group ID
IDENTITY_who => special who string (e.g. OWNER@, GROUP@, EVERYONE@)
ACE_TYPE => One of the following ACE Type:
a : allow
d : deny
l : alarm
u : audit
ACE MASK => One or more of the following Mask value Key without separator:
r : READ_DATA or LIST_DIRECTORY
w : WRITE_DATA or ADD_FILE
p : APPEND_DATA or ADD_SUBDIRECTORY
R : READ_NAMED_ATTRS
W : WRITE_NAMED_ATTRS
x : EXECUTE or SEARCH_DIRECTORY
D : DELETE_CHILD
a : READ_ATTRIBUTES
A : WRITE_ATTRIBUTES
d : DELETE
c : READ_ACL
C : WRITE_ACL
o : WRITE_OWNER
s : SYNCHRONIZE
ACE_FLAGS (Optional) => One or more of the following Attribute Key without separater:
fi : FILE_INHERIT
di : DIRECTORY_INHERIT
oi : INHERIT_ONLY
ni : NO_PROPAGATE_INHERIT
sf : SUCCESSFUL_ACCESS_ACE_FLAG
ff : FAILED_ACCESS_ACE_FLAG
s
, AIX does not take
any action concerning this value key. The AIX operating system stores
and preserves the s
value key but this value key
does not have any meaning to AIX.When the WRITE_OWNER Ace_Mask is set to Ace_Type allow
, users can change ownership of the file to themselves only.
chdev -l sys0 -a nfs4_acl_compat=compatibleYou must reboot the system after running the chdev command before the configuration change will take place.
If you switch your system back and forth between the two modes, you need to be aware that NFS4 ACLs generated by the AIX operating system in secure mode might not be accepted by other platforms even if the system was changed back to compatibility mode.
Example:
u:user1(aa@ibm.com): a rwp fidi
*s:(OWNER@): d x dini * This line is a comment
g:staff(jj@jj.com): a rx
s:(GROUP@): a rwpx fioi
u:2: d r di * This line shows user bin (uid=2)
g:7: a ac fi * This line shows group security (gid=7)
s:(EVERYONE@): a rca ni
Binary format for NFS4 ACL
The NFS4 ACL binary format is defined in /usr/include/sys/acl.h and is implemented in the current AIX release.
NFS4 ACL example
The following example shows an NFS4 ACL applied on a directory (such as, j2eav2/d0):
s:(OWNER@): a rwpRWxDdo difi * 1st ACE
s:(OWNER@): d D difi * 2nd ACE
s:(GROUP@): d x ni * 3rd ACE
s:(GROUP@): a rx difi * 4th ACE
s:(EVERYONE@): a c difi * 5th ACE
s:(EVERYONE@): d C difi * 6th ACE
u:user1: a wp oi * 7th ACE
g:grp1: d wp * 8th ACE
u:101: a C * 9th ACE
g:100: d c * 10th ACE
- The first ACE indicates that the owner has the following privileges
on /j2eav2/d0 and all its offspring created after
this ACL is applied:
READ_DATA (= LIST_DIRECTORY)
WRITE_DATA (=ADD_FILE)
APPEND_DATA (= ADD_SUBDIRECTORY)
READ_NAMED_ATTR
WRITE_NAMED_ATTR
EXECUTE (=SEARCH_DIRECTORY)
DELETE_CHILD
DELETE
WRITE_OWNER
- The second ACE indicates the owner is denied the privilege for
DELETE_CHILD
(deleting the files or subdirectories created under /j2eav2), but owner can still delete them because of the first ACE, which allows owner the privilege forDELETE_CHILD
. - The third ACE indicates all members of the group for the object
(/j2eav2/d0) are denied the privilege for
EXECUTE (=SEARCH_DIRECTORY)
, but the owner is still allowed that privilege by the first ACE. This ACE can not be propagated to all of its offsprings because theNO_PROPAGATE_INHERIT
flag is specified. This ACE is applied only to the directory /j2eav2/d0 and its immediate child files and subdirectories. - The fourth ACE indicates that every member of the group of the
object (/j2eav2/d0) is allowed the privilege
for
READ_DATA (= LIST_DIRECTORY)
andEXECUTE (=SEARCH_DIRECTORY)
on /j2eav2/d0 and all its offsprings. However, because of third ACE group members (except the owner) are not allowed the privilege forEXECUTE (=SEARCH_DIRECTORY)
on the /j2eav2/d0 directory and its immediate child files and subdirectories. - The fifth ACE indicates that everyone is allowed the privilege
for
READ_ACL
on the /j2eav2/d0 directory and any offspring that are created after this ACL is applied. - The sixth ACE indicates that everyone is denied the privilege
for
WRITE_ACL
on the /j2eav2/d0 directory and any offspring. The owner always has the privilege forWRITE_ACL
on files and directories with NFS4 ACLs. - The seventh ACE indicates that user1 has the privilege for
WRITE_DATA (=ADD_FILE)
andAPPEND_DATA (= ADD_SUBDIRECTORY)
on all the offspring of the /j2eav2/d0 directory but not on the /j2eav2/d0 directory itself. - The eighth ACE indicates that all the members of grp1 are denied
the privilege for
WRITE_DATA (=ADD_FILE)
andAPPEND_DATA (= ADD_SUBDIRECTORY)
. This ACE does not apply to the owner even it belongs to grp1 because of the first ACE. - The ninth ACE indicates that the user with UID 101 has
the privilege for
WRITE_ACL
, but no one, except the owner has the privilege forWRITE_ACL
because of the sixth ACE. - The tenth ACE indicates that all the members of the group with GID 100 are denied for
READ_ACL
, but they will have this privilege because of the fifth ACE.