Jump to content United States-English
HP.com Home Products and Services Support and Drivers Solutions How to Buy
» Contact HP
More options
HP.com home
HP-UX System Administrator's Guide: Security Management: HP-UX 11i Version 3 > Chapter 6 File System Security

Using JFS ACLs


Technical documentation

Complete book in PDF
» Feedback
Content starts here

 » Table of Contents

 » Glossary

 » Index

This section describes JFS ACLs and how to use them.

NOTE: To use JFS ACLs, you must have a VxFS file system using disk layout Version 4. See vxupgrade(1M) for information about upgrading the file system to Version 4.

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:

user::rw- group::r-- class:r-- other:---
  • The user entry indicates the permissions of the owner of the file and maps directly to the owner permission bits. Because the first entry applies to the owner of the file, no user name needs to be indicated. This example ACL entry grants read and write access to the file's owner.

  • The group and class entries specify the permission granted to members of the file's owning group. The example ACL entry grants read-only access to the file's owning group. The group and class entries are described more in Section .

  • The other entry is a catch-all entry that specifies permissions for anyone who is not granted or denied permission by any other entry. The example other entry denies access to all users who are not the owner of the file nor in the file's owning group.

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:

  • Replace a file's entire ACL, including the default ACL on a directory.

  • Add, modify, or delete one or more entries, including default entries on directories.

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

  • The bits representing owner permissions are represented by a user entry without a specified user ID.

  • The bits representing group permissions are represented by a group entry without a specified group ID.

    An ACL must contain one each of these special user and group entries. The ACL can have any number of additional user entries and group entries, but these must all contain a user ID or group ID, respectively. An ACL has only one other entry, representing the permission bits for permissions to be granted to other users.

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:

  • The class ACL entry no longer necessarily equals the owning group ACL entry.

  • The chmod command affects the class ACL entry, not the owning group entry.

  • You must use the setacl command to change the owning group entry.

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:

$ ls -l exfile -r--r--r-- 1 jsmith users 12 Sep 20 15:02 exfile

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

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

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:

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

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.

$ setacl -m u:guest:r-- exfile $ setacl -m g:dev:r-x exfile $ getacl exfile# file: exfile # owner: jsmith # group: users user::rw- user:guest:r-- group::rw- group:dev:r-x class:rwx other:rw-

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.

$ chmod g-wx exfile $ getacl exfile # file: exfile # owner: jsmith # group: users user::rw- user:guest:r-- group::rw- # effective:r-- group:dev:r-x # effective:r-- class:r-- other:rw-

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.

$ ls -l exfile -rw-r--rw-+ 1 jsmith users 12 Sep 20 15:02 exfile

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:

  • The corresponding nondefault ACL entries are created, so that the desired permissions are granted and denied for the directory, just as for any file created in the directory.

  • The default entries themselves are copied, so that the new subdirectory has the same default ACL as the parent directory.

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:

$ setacl -m d:u:boss:r,d:u:jjones:r,d:u:dev:r projectdir
$ getacl projectdir
# file: projectdir
# owner: jsmith
# group: users

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

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.

Printable version
Privacy statement Using this site means you accept its terms Feedback to webmaster
© 2008 Hewlett-Packard Development Company, L.P.