Using JFS ACLs

Definition of a JFS ACL

A JFS ACL contains one-line entries naming specific users and groups and indicating what access is granted to each. The presence of a JFS ACL also changes the meaning of the group permission bits, which are displayed using the ls -l command.

A JFS ACL always has at least four entries: a user entry, a group entry, a class entry, and an other entry. When a JFS ACL contains only these four entries, the permissions it grants are exactly the same as the permissions represented by the standard UNIX system permission bits.

How the System Generates a JFS ACL

Whenever a file is created on a JFS file system, the system initializes a minimal JFS ACL for the file, containing a user entry for the owner permissions, a group entry for the owning group permissions, a class entry for the owning group permissions, and an other entry for the other group permissions. Additional entries can be added by the user, or as a result of default entries specified on the parent directory.

Minimal JFS ACL

An ACL with the four basic entries defined previously is called a minimal JFS ACL. An example minimal ACL looks like this:

The permission bits displayed by ls -l for this file would look like this:

The next section describes how additional JFS ACL entries affect file access and the interpretation of the permission bits.

Additional JFS ACL user and group Entries

If you want to grant or deny access to specific users and groups on the system, you can add up to 13 more user and group entries to the four minimal entries described in the previous section.

For example, the following entry in the ACL of a file grants read, write, and execute access to a user logged in as boss:

In the next example, an ACL with the following entry denies access to a user in the group spies:

JFS ACL group and class Entries

In a file with a minimal ACL, the owning group and class ACL entries are identical. However, in a file with additional entries, the owning group and class ACL entries are distinct. The owning group entry grants permissions to a specific group: the owning group.

The class entry is more general; it specifies the maximum permissions that can be granted by any of the additional user and group entries.

If a particular permission is not granted in the class entry, it cannot be granted by any ACL entries except for the first user (owner) entry and the other entry. Any permission can be denied to a particular user or group. The class entry functions as an upper bound for file permissions.

When an ACL contains more than one group or user entry, the additional user and group entries are referred to as the group class entries, because the effective permission granted by any of these additional entries is limited by the class entry.

Using the setacl and getacl Commands

Use the setacl and getacl commands to change and view ACLs.

Use the setacl command to change the ACL in one of the following ways:

The getacl command displays the entries in the ACL. File permission bits for user and group are translated into special cases of these entries:

See setacl(1) and getacl(1) for command descriptions.

Effect of chmod on class Entries

When a file has a minimal ACL, the owning group and class ACL entries are identical, and chmod affects both of them. However, when a file contains additional, optional entries in the ACL, the following consequences occur:

Example of Changing a Minimal JFS ACL

To illustrate the function of the JFS ACL class entry, this section describes how chmod and setacl affect a file with a minimal JFS ACL and a file with group class entries.

	NOTE: Further details about the use of the getacl and setacl commands are in Section . Refer also to getacl(1) and setacl(1).

Consider a file, exfile, with read-only (444) permissions and a minimal JFS ACL. The ls -l command shows the permissions for exfile:

The getacl command lists the following output for exfile, which is a minimal JFS ACL:

Using the chmod command to add write permissions to exfile changes both the owning group and the class ACL entries. For example, look at the getacl command output:

Now add additional user and group entries, that will affect the class ACL entry but not the owning group entry. The first setacl command that follows grants read-only permission to user guest; the other ACL entries are unaffected. However, the second setacl command grants read-execute permissions to the group dev, and the upper bound on permissions (the class entry) is extended to include execute permission.

Next, the chmod command removes write and execute permission from group, and actually reduces the class permissions to read-only. The owning group permissions, while unchanged, are effectively reduced to read-only as well.

The other permissions are unchanged. The class entry does not limit the access that can be granted by the first user (owner) entry or the other entry.

Next the ls -l command lists the permissions of exfile. The plus sign (+) at the end of the permissions string indicates that there is an ACL for the file.

Default JFS ACLs

You might want all the files created in a directory to have certain ACL entries. For example, you can allow another person to write to any file in a directory of yours when the two of you are working on something together.

You can put an ACL entry granting the desired access on every file in the directory, but every time you create a new file, you have to add that entry again. Using default ACL entries, you can get the system to do this for you automatically every time you create a file.

A default ACL entry appears as follows:

Default ACLs can only be placed only on a directory and have no influence on what access to the directory is granted to a user. The default ACL is applied to files created in the directory.

When the newly created file is a directory, the default ACL entries have two effects:

For example, if you want any files created in the directory projectdir to be readable by certain users, you can create the appropriate default entries, as follows:

$ getacl projectdir
# file: projectdir
# owner: jsmith
# group: users
user::rw-
user:boss:rw-
user:jjones:rw-
user:jdoe:---
group::rw-
group:dev:rw-
class:rw-
other:---
default:user:boss:r---
default:user:jjones:r--
default:group:dev:r--

If the newly created file is a directory, the same ACL entries are generated. In addition, the default entries themselves are also placed in the ACL.

With these entries in place, any new file created in the directory projectdir will have an ACL like that shown previously without the default entries.

Changing JFS ACL with the setacl Command

This section presents more examples of using the setacl command.

Using the Modify and Delete Options

The following setacl command uses the -m (modify) option to give read-only access to the user boss for the junk file:

$ setacl -m u:boss:r-- junk

To grant read and write access to everyone in the group dev, use the group (g:) parameter with the setacl -m command:

$ setacl -m g:dev:rw- junk

The -d option deletes an entry. With -d, do not specify any permissions in the ACL entry. For example, the following command deletes the entry for the group dev:

$ setacl -d g:dev junk

Using the -f Option

If you are adding or changing several entries, you can use a different procedure. You can save the ACL to a file, edit the file, and then apply this new ACL to the file. For example, save the ACL to a file with this command:

$ getacl junk > junk.acl

Edit the file so that it appears as follows:

$ cat junk.acl # file: junk # owner: user1 # group: group1 user::rw- user:user2:rw- user:user3:rw- user:user4:--- user:user5:r-- group::rw- group:group2:rw- group:group3:r-- group:group4:--- group:group5:rw- class:rw- other:r--

Apply the ACL to the file using the setacl -f command:

$ setacl -f junk.acl junk

Effective Permissions and setacl -n

Normally, setacl recalculates the class entry to ensure that permissions granted in the additional ACL entries are granted. If you specify the -n option, the class entry is not recalculated; the existing value is used. This means that some permissions granted by the ACL entries will not be granted in practice.

For example, this ACL is modified with the setacl -n command to add read and execute permissions to group dev as follows:

$ getacl exfile # file: exfile # owner: jsmith # group: users user::rw- group::rw- class:rw- other:rw-

$ setacl -n -m group:dev:r-x exfile $ getacl exfile # file: exfile # owner: jsmith # group: users user::rw- group::rw- group:dev:r-x #effective r-- class:rw- other:rw-

The group dev ACL entry is added as specified, but execute permission is not actually granted. Execute permission is denied by the class entry, and the class entry was not recalculated because -n was specified. If -n was not used, class would have been reset to class:rwx, and the effective comment would not be there.