THe NFSv4 (Network File System – Version 4) protocol introduces a new ACL (Access Control List) format that extends other existing ACL formats. NFSv4 ACL is easy to work with and introduces more detailed file security attributes, making NFSv4 ACLs more secure. Several operating systems like IBM® AIX®, Sun Solaris, and Linux® have implemented NFSv4 ACL in their filesystems.
Currently, the filesystems that support NFSv4 ACL in IBM AIX 5L version 5.3 and above are NFSv4, JFS2 with EAv2 (Extended Journaled Filesystem with Extended Attributes format version 2), and General Parallel Filesystem (GPFS). In Sun Solaris, this ACL model is supported by ZFS. In RedHat Linux, NFSv4 supports NFSv4 ACLs.
An Access Control List (ACL) is used to specify access permissions to filesystem objects, like files and directories. Is a list of many Access Control Entries (ACEs), in which each entry defines a user or a group, and different permissions to each of them.
ZFS file system, introduced by Sun, is available in the Solaris 10 OS pack.
ZFS supports the NFSv4 ACL model, and has implemented the commands in the form of new options to the existing ls and chmod commands. Thus, the ACLs can be set and displayed using the chmod and ls commands; no new command has been introduced. Because of this, it is very easy to work with ACLs in ZFS.
ZFS ACLs follow a well-defined format. The format and the entities involved in this format are:
Syntax A
ACL_entry_type:Access_permissions/…/[:Inheritance_flags]:deny or allow
|
ACL_entry_type includes "owner@", "group@", or "everyone@".
For example:
group@:write_data/append_data/execute:deny |
Syntax B
ACL_entry_type: ACL_entry_ID:Access_permissions/…/[:Inheritance_flags]:deny or allow
|
ACL_entry_type includes "user", or "group".
ACL_entry_ID includes "user_name", or "group_name".
For example:
user:samy:list_directory/read_data/execute:allow |
Inheritance flags
f : FILE_INHERIT
d : DIRECTORY_INHERIT
i : INHERIT_ONLY
n : NO_PROPAGATE_INHERIT
S : SUCCESSFUL_ACCESS_ACE_FLAG
F : FAILED_ACCESS_ACE_FLAG
|
Listing ACLs of ZFS files and directories
ACLs can be listed using the ls command using the -v and -V options. For listing directory ACLs, use the -d option.
| Operation | Command |
|---|---|
| Listing ACL entries of files | ls –[v | V] <file_name> |
| Listing ACL entries of dirs | ls –d[v | V] <dir_name> |
Example for listing ACLs of a file
ls -v file.1
-rw-r--r-- 1 root root 2703 Nov 4 12:37 file.1
0:owner@:execute:deny
1:owner@:read_data/write_data/append_data/write_xattr/write_attributes/
write_acl/write_owner:allow
2:group@:write_data/append_data/execute:deny
3:group@:read_data:allow
4:everyone@:write_data/append_data/write_xattr/execute/write_attributes/
write_acl/write_owner:deny
5:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize:allow
|
Example for listing ACLs of a directory
# ls -dv dir.1
drwxr-xr-x 2 root root 2 Nov 1 14:51 dir.1
0:owner@::deny
1:owner@:list_directory/read_data/add_file/write_data/add_subdirectory/
append_data/write_xattr/execute/write_attributes/write_acl/write_owner:allow
2:group@:add_file/write_data/add_subdirectory/append_data:deny
3:group@:list_directory/read_data/execute:allow
4:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr /
write_attributes/write_acl/write_owner:deny
5:everyone@:list_directory/read_data/read_xattr/execute/read_attributes /
read_acl/synchronize:allow
|
Example for listing ACLs in a compact format
# ls -Vd dir.1 drwxr-xr-x 2 root root 2 Sep 1 05:46 d owner@:--------------:------:deny owner@:rwxp---A-W-Co-:------:allow group@:-w-p----------:------:deny group@:r-x-----------:------:allow everyone@:-w-p---A-W-Co-:------:deny everyone@:r-xp--a-R-c--s:------:allow |
In above examples, ACLs are displayed in a compact format. In this, access permissions and inheritance flags are displayed using masks. One ACL entry is displayed in each line, making the view easier to understand.
Modifying ACLs of ZFS files and directories
ACLs can be set or modified using the chmod command. The chmod command uses the ACL-specification, which includes the ACL-format (Syntax A or B), listed earlier.
| Operation | Command |
|---|---|
| Adding an ACL entry by index-ID | # chmod Aindex_ID+acl_specification filename |
| Adding an ACL entry for a user | # chmod A+acl_specification filename |
| Removing an ACL entry by index_ID | # chmod Aindex_ID- filename |
| Removing an ACL entry by user | # chmod A-acl_specification filename |
| Removing an ACL from a file | # chmod A- filename |
| Replacing an ACL entry at index_ID | # chmod Aindex_ID=acl_specification filename |
| Replacing an ACL of a file | # chmod A=acl_specification filename |
Examples of ZFS ACLs modifications
List ACL entries
# ls –v a
-rw-r--r-- 1 root root 0 Sep 1 04:25 a
0:owner@:execute:deny
1:owner@:read_data/write_data/append_data/write_xattr/write_attributes/
write_acl/write_owner:allow
2:group@:write_data/append_data/execute:deny
3:group@:read_data:allow
4:everyone@:write_data/append_data/write_xattr/execute/write_attributes/
write_acl/write_owner:deny
5:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize:allow
|
Add ACL entries
# chmod A+user:samy:read_data:allow a
# ls -v a
-rw-r--r--+ 1 root root 0 Sep 1 02:01 a
0:user:samy:read_data:allow
1:owner@:execute:deny
2:owner@:read_data/write_data/append_data/write_xattr/write_attributes/
write_acl/write_owner:allow
3:group@:write_data/append_data/execute:deny
4:group@:read_data:allow
5:everyone@:write_data/append_data/write_xattr/execute/write_attributes/
write_acl/write_owner:deny
6:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize:allow
# chmod A1+user:samy:execute:deny a
# ls -v a
-rw-r--r--+ 1 root root 0 Sep 1 02:01 a
0:user:samy:read_data:allow
1:user:samy:execute:deny
2:owner@:execute:deny
3:owner@:read_data/write_data/append_data/write_xattr/write_attributes/
write_acl/write_owner:allow
4:group@:write_data/append_data/execute:deny
5:group@:read_data:allow
6:everyone@:write_data/append_data/write_xattr/execute/write_attributes/
write_acl/write_owner:deny
7:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize:allow
|
Replace ACL entries
# chmod A0=user:samy:read_data/write_data:allow a
# ls -v
total 2
-rw-r--r--+ 1 root root 0 Sep 1 02:01 a
0:user:samy:read_data/write_data:allow
1:user:samy:execute:deny
2:owner@:execute:deny
3:owner@:read_data/write_data/append_data/write_xattr/write_attributes/
write_acl/write_owner:allow
4:group@:write_data/append_data/execute:deny
5:group@:read_data:allow
6:everyone@:write_data/append_data/write_xattr/execute/write_attributes/
write_acl/write_owner:deny
7:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize:allow
# chmod A=user:samy:read_data/write_data/append_data:allow a
# ls -v a
----------+ 1 root root 0 Sep 1 02:01 a
0:user:samy:read_data/write_data/append_data:allow
|
ACLs can also be modified using the masks instead of specifying complete names.
Modifying ACL entries using masks
# ls -V a -rw-r--r--+ 1 root root 0 Sep 5 01:50 a user:samy:--------------:------:deny user:samy:rwx-----------:------:allow owner@:--x-----------:------:deny owner@:rw-p---A-W-Co-:------:allow group@:-wxp----------:------:deny group@:r-------------:------:allow everyone@:-wxp---A-W-Co-:------:deny everyone@:r-----a-R-c--s:------:allow # chmod A1=user:samy:rwxp:allow a # ls -V a -rw-r--r--+ 1 root root 0 Sep 5 01:50 a user:samy:--------------:------:deny user:samy:rwxp----------:------:allow owner@:--x-----------:------:deny owner@:rw-p---A-W-Co-:------:allow group@:-wxp----------:------:deny group@:r-------------:------:allow everyone@:-wxp---A-W-Co-:------:deny everyone@:r-----a-R-c--s:------:allow |
Remove ACL entries
# ls -v a
-rw-r-----+ 1 root root 0 Sep 5 01:50 a
0:user:samy:read_data/write_data/execute:allow
1:owner@:execute:deny
2:owner@:read_data/write_data/append_data/write_xattr/write_attributes/
write_acl/write_owner:allow
3:group@:write_data/append_data/execute:deny
4:group@:read_data:allow
5:everyone@:read_data/write_data/append_data/write_xattr/execute/
write_attributes/write_acl/write_owner:deny
6:everyone@:read_xattr/read_attributes/read_acl/synchronize:allow
# chmod A- a
# ls -v a
-rw-r----- 1 root root 0 Sep 5 01:50 a
0:owner@:execute:deny
1:owner@:read_data/write_data/append_data/write_xattr/write_attributes/
write_acl/write_owner:allow
2:group@:write_data/append_data/execute:deny
3:group@:read_data:allow
4:everyone@:read_data/write_data/append_data/write_xattr/execute/
write_attributes/write_acl/write_owner:deny
5:everyone@:read_xattr/read_attributes/read_acl/synchronize:allow
# chmod A5- a
# ls -v a
-rw-r----- 1 root root 0 Sep 5 01:50 a
0:owner@:execute:deny
1:owner@:read_data/write_data/append_data/write_xattr/write_attributes/
write_acl/write_owner:allow
2:group@:write_data/append_data/execute:deny
3:group@:read_data:allow
4:everyone@:read_data/write_data/append_data/write_xattr/execute/
write_attributes/write_acl/write_owner:deny
|
The Enhanced Journaled File System (JFS2) is built into the base AIX operating system. To have the NFSv4 ALC support on JFS2 filesystem, you need to enable "Extended Attribute Format - Version 2" at the time of creating the filesystem. This feature cannot be enabled or disabled once the filesystem is created.
In subsequent references to JFS2, this article assumes that "Extended Attribute Format - Version 2" is enabled.
The format and the entities involved in this format are:
Syntax
IDENTITY ACE_TYPE ACE_MASK INHERITANCE_AND_AUDIT_ATTRS
Where:
IDENTITY has format: 'IDENTITY_type:IDENTITY_name(IDENTITY_who):'
Where:
IDENTITY_type is one of the following:
u : user
g : group
s : special who string (IDENTITY_who must be a special who)
IDENTITY_name => user/group name
IDENTITY_who => who string
ACE_TYPE is one of the following ACE Type:
a : allow
d : deny
l : alarm
u : audit
|
Inheritance flags
INHERITANCE_AND_AUDIT_ATTRS (Optional) is one or more of the following:
fi : FILE_INHERIT
di : DIRECTORY_INHERIT
oi : INHERIT_ONLY
ni : NO_PROPAGATE_INHERIT
sf : SUCCESSFUL_ACCESS_ACE_FLAG
ff : FAILED_ACCESS_ACE_FLAG
|
Listing ACLs of JFS2 files and directories
JFS provides the following commands related to ACLs.
| Operation | Command |
|---|---|
| Display ACLs of a file | aclget <filename> |
| Set ACLs of a file | aclput [-i infile] [-t acl_type] [-v] <filename> |
| Edit ACLs of a file | acledit [-t acl_type] <filename> |
| Converts ACLs of a file from one type to another | aclconvert [ -R ] -t <acltype> <filename> |
| Gets ACL types supported by a file system path | aclgettypes <filename> |
In JFS2 partition, AIX Classic (AIXC) ACLs are enabled by default, and not NFS4 ACLs. You need to convert the AIXC ACLs to NFS4.
The following command lists the ACLs of a new file in JFS2 partition:
Display ACLs
# aclget file1
*
* ACL_type AIXC
*
attributes:
base permissions
owner(root): rw-
group(system): r--
others: r--
extended permissions
disabled
|
In this example, AIXC shows that these are the AIX classic ACLs.
To convert to any other type, you need to know what ACL types are supported by this filesystem.
Display supported ACL types:
# aclgettypes file1
Supported ACL types are:
AIXC
NFS4
|
Now, you can convert the AIXC ACLs to NFS4 as follows:
Convert ACLs from AIX classic form to NFSv4 form
# aclconvert -t NFS4 file1 # aclget a * * ACL_type NFS4 * * * Owner: root * Group: system * s:(OWNER@): a rwpRWaAdcCs s:(OWNER@): d xo s:(GROUP@): a rRadcs s:(GROUP@): d wpWxACo s:(EVERYONE@): a rRadcs s:(EVERYONE@): d wpWxACo |
Modifying ACLs of JFS2 files and directories
To modify the ACLs, you can use either the aclput or acledit command. The best way
to set the ACLs is first to get the ACLs of a file using the aclget command, and
save it in a file. Then, modify the ACLs in that file, and store them using
aclput –i <input_acl_file>.
The acledit command uses an editor to display and modify the ALCs. You need to set the environment variable EDITOR before you use the acledit command.
To avoid converting the ACLS of new files from AIXC type to NFS4 inside a directory each time, set the appropriate Inheritance flag in that directory.
The previous commands can also be used for NFSv4 filesystem to manage NFSv4 ACLs on AIX.
The IBM General Parallel File System (GPFS) is a powerful clustered file system. It provides several advance features that should be in a clustered environment and provides NFSv4 ACL support on AIX and Linux.
GPFS supports both NFS4 and POSIX ACL formats.
Traditionally, a POSIX GPFS ACL looks like this:
GPFS POSIX ACLs
#owner:guest #group:usr user::rwxc group::rwx- #effective:rw— other::--x- mask::rw-c user:samy:rwxc #effective:rw-c group:audit:rwx- #effective:rw-- group:system:-w-- |
In this example, apart from the general modebits rwx,
there is a new bit c, which is a GPFS specific bit,
and stands for ACL Control. If this bit is set for any user, the user can modify the
ACLs on that file or directory.
Also, notice the mask ACL entry. It is not the ACL
entry for any particular user or group, rather it is the filter that we can
apply to the ACLS of all the groups, all the users, and the owning group of the
file or directory. It represents the maximum permissions that these three
entries can have. Note that it does not apply to the owning user and other entries.
In the previous example, you can see that mask is set
to rw-c. So, this is the maximum permissions that can
be given to other users, like samy, whose ACL is
rwxc, but the effective ALC would be rw-c only.
The NFS4 representation of GPFS ACLs consists of three lines for each ACL entry.
Syntax
Format for first line:
IDENTITY_TYPE:IDENTITY_NAME:PERMISSIONS_BITS:TYPE[:INHERITANCE_FLAGS]
Where:
IDENTITY_TYPE is one of the following:
user : A normal user.
group : A normal Group.
special : File owning owner, group, or everyone.
IDENTITY_NAME is one of the following:
If IDENTITY_TYPE is user or group, then IDENTITY_NAME is name of user or group.
If IDENTITY_TYPE is special, then IDENTITY_NAME is either “owner@”, “group@”
or “everyone@”.
PERMISSIONS is one or more of the following:
r : Read.
w : Write.
x : Execute.
c : ACL Control.
TYPE is one of the following:
allow
deny
Next 2 lines represent the list of access permissions.
|
Inheritance flags
INHERITANCE_FLAGS is one or more of the following:
FileInherit
DirInherit
InheritOnly
|
Example
group:staff:r-x-:allow
(X)READ/LIST (-)WRITE/CREATE (-)MKDIR (-)SYNCHRONIZE (-)READ_ACL
(X)READ_ATTR (-)READ_NAMED
(-)DELETE (-)DELETE_CHILD (-)CHOWN (X)EXEC/SEARCH (-)WRITE_ACL
(-)WRITE_ATTR (-)WRITE_NAMED
|
| Operation | Command |
|---|---|
| Display ACLs of a file | mmgetacl <filename> |
| Adding, replacing, removing ACL entries | mmputacl –i <input_acl_file> <filename> |
| Edit ACLs of a file | mmeditacl <filename> |
| Deleting ACL entries | mmdelacl <filename> |
Initially, the file contains the POSIX ACLs by default. POSIX ACLs can be
displayed into the NFS4 form by using the -k nfs4 option in
the mmgetacl command. To change this default behavior, set the default
ACL as NFS4 on the GPFS filesystem by using mmchfs
<device> –k nfs4.
If you set the NFS4 ACL on a file that has POSIX ACL set, it will be overwritten by the NFS4 ACL.
Comparison between ZFS, JFS2, and GPFS ACL operations
ZFS supports the ls and chmod commands, to list and modify the ACLs.
In the case of JFSv2 with Extended Attributes v2 (JFS2 with EAv2), ACLs can be listed
and modified using the acl* set of commands. By default, for the new files
created, only the AIX-classic ACLs are enabled, and NFS4 ACLs are disabled. This
is so the ACL Inheritance flags are not set on the parent directory. The NFS4
ACLs can be enabled using the aclconvert –t NFS4 <path or
file_name> command.
The GPFS mmgetacl, mmputacl, mmdelacl, mmeditacl commands are used for ACL operations.
| Operation | ZFS Commands | JFS2ea2 Commands | GPFS Commands |
|---|---|---|---|
| Display ACLs of a file | ls –v <file_name> | aclget <file_name> | mmgetacl –knfs4 <file_name> |
| Adding ACL entries | chmod Aindex_ID+acl_specification <file_name> | aclput –t NFS4 <file_name> | mmputacl –i input_acl_file <file_name> |
| chmod A+acl_specification <file_name> | acledit <file_name> | mmeditacl <file_name> | |
| Replacing ACL entries | chmod Aindex_ID=acl_specification <file_name> | acledit –t NFS4 <file_name> | mmputacl –i input_acl_file <file_name> |
| chmod A=acl_specification <file_name> | mmeditacl <file_name> | ||
| Removing ACL entries | chmod Aindex_ID- filename | acledit <file_name> | mmeditacl <file_name> |
| chmod A-acl_specification <file_name> | |||
| chmod A- <file_name> |
On ZFS files, when the chmod command is used to modify the basic permission bits, the extended or explicit NFS ACLS are not deleted. On changing the permission bits, the NFS ACLs are set accordingly, and vice versa.
On the other hand, for files in JFS2ea2, the chmod command must only be used to modify permission bits, other than those used in ACLs. Only the setuid, setgid, or sticky bits can be modified by the chmod command, without affecting NFS ACLs. If you try to change any of the UNIX® permission bits, then all the NFS ACLs will be destroyed, and the corresponding AIXC ACLs will be set.
In the case of GPFS, the result of using chmod is similar. If the -k nfs4 option was set on the GPFS filesystem, then all the ACL
entries apart from owner@, group@, and everyone@ are deleted. If -k nfs4 was not set on the GPFS filesystem, then running chmod
deletes all of
the NFS4 ACLs, and the POSIX ACL entries of owner@, group@, and everyone@ are left.
Effects of the chmod command on JFS2
# aclget a * * ACL_type NFS4 * * * Owner: root * Group: system * s:(OWNER@): a rwpRWxaAdcCs s:(OWNER@): d o s:(GROUP@): a rRadcs s:(GROUP@): d wpWxACo s:(EVERYONE@): a rRadcs s:(EVERYONE@): d wpWxACo # chmod 744 a # aclget a * * ACL_type AIXC * attributes: base permissions owner(root): rwx group(system): r-- others: r-- extended permissions disabled |
Learn
-
"Managing GPFS access control lists and NFS export" - All about GPFS ACLs
- The complete
ZFS Administration Guide
- Browse the
technology bookstore
for books on these and other technical topics.
-
The AIX and UNIX developerWorks zone provides a wealth of information relating to all aspects of AIX systems administration.
-
developerWorks technical events and webcasts: Stay current with developerWorks technical events and webcasts.
-
Podcasts: Tune in and catch up with IBM technical experts.
Discuss
-
Participate in the AIX and UNIX forums:
- AIX Forum
- AIX Forum for developers
- Cluster Systems Management
- IBM Support Assistant Forum
- Performance Tools Forum
- Virtualization Forum
- More AIX and UNIX Forums
Samyak Jain is a Staff Software Engineer at the IBM India Software Labs. He has worked for IBM for the past three years, on Enterprise File-system, AFS. He is currently working as Level 3 support team member. He holds a Bachelor of Engineering degree in Computer Science from Rajeev Gandhi University, Bhopal, India. You can contact him at samyjain@in.ibm.com.
Table of contents
Local resources
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
