|
|
Access Control Lists (ACLs) give you a more precise way to control access to files. The ACL contains one-line entries naming specific users and groups and indicating what access is granted to each. The presence of an ACL also changes the meaning of the ``group'' permission bits displayed using the ls-l command.
There are always at least four entries in an ACL, a user entry, a group entry, a class entry, and an other entry. When an ACL contains only four entries, the permissions it grants are exactly the same as the permissions represented by the permission bits.
While having such an ACL (we will call it a minimal ACL) provides no greater functionality than the permission bits alone, we will start by describing a minimal ACL, and augment it with additional entries to show how the mechanism works.
The first entry in a minimal ACL indicates the permissions that the owner of the file gets, and maps directly to the owner permission bits. Because it applies to the owner of the file, no indication of the user's name is needed. An ACL entry that grants read and write access to the file's owner would look like this:
user::rw-The second and third entries in a minimal ACL specify the permission granted to members of the file's owning group; the permissions specified in these entries are exactly equal. For example, ACL entries granting read-only access to the file's owning group would look like this:
group::r-- class::r--The fourth and last entry in a minimal ACL is a catch-all entry that specifies the permissions for anyone who isn't granted or denied permission by any other entry. An other entry that denies access to all users not the owner of the file nor in the file's owning group would look like this:
other:---The minimal ACL described above would look like this in its entirety:
user::rw- group::r-- class::r-- other:---The permission bits displayed by ls -l for this file would look like this:
rw-r-----In the case of a minimal ACL, there is a clear correspondence between the ACL entries and the permission bits.
The next section describes how additional ACL entries affect file access and the interpretation of the permission bits.
If you want to specifically grant and/or deny access to specific users and/or groups on the system, you can add more user and group entries to the four minimal entries described in the previous section.
Additional user entries grant and deny access to specific user IDs on your system. For example, the following entry in the ACL of a file grants read, write, and execute access to a user logged in as archer:
user:archer:rwxSimilarly, additional group entries grant and deny access to specific group IDs on your system. For example, an ACL with the following entry would deny access to a user in the group spies:
group:spies:---
In an ACL that contains more than one group entry and/or more than one user entry, the class entry 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 and/or user entry, the collection of additional user and group entries are referred to as the group class entries, since the effective permission granted by any of these additional entries is limited by the class entry.
If there are additional entries in the ACL, the class ACL entry will no longer necessarily equal the value of the permissions for the owning group reported by ls -l. This feature is useful, because it means that the chmod command can usefully affect the permissions of a file that has additional ACL entries.
For example, by changing the permission bits of a file to:
rwx------the class entry in the ACL is set to:
class:---This means that any additional group entries in the ACL cannot grant any access to the file. If the permission bits were set to:
rwxr-----the class ACL entry would be:
class:r--Any group entries would be able to grant read access, but not write or execute access.
The class entry does not limit the access that can be granted by the first user (owner) entry or the other entry.
Often, you will want all the files created in a directory to have certain ACL entries. For example, you might want to allow another person to write to any file in a directory of yours where 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 will have to add that entry again. Using default ACL entries, you can get the system to do this for you automatically every time a file is created.
A default ACL entry looks like this:
default:user:archer:rw-It can be placed only on a directory, never on an ordinary file. It never has any influence on what access is granted to a user for the directory it is placed on. All it does is cause the specified entry to be included in the ACL of any file created in the directory.
If the newly created file is a directory, the default ACL entries have two affects. First, the corresponding non-default 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. Second, the default entries themselves are copied, so that new sub-directory has the same default ACL as the parent directory.
For example, if you want any files created in the directory
poentkarto
to be readable by certain users, you could create the
appropriate default entries as shown in
``An ACL with default entries''.
$ getacl poentkarto
# file: poentkarto
# owner: fletcher
# group: tourney
user::rw-
user:archer:rw-
user:bowman:rw-
user:hunter:---
group::rw-
group:judges:rw-
class:rw-
other:---
default:user:archer:r--
default:user:bowman:r--
default:group:judges:r--
An ACL with default entries
With these entries in place, any new file created in the
directory
poentkarto
would have an ACL like that shown in
``Effect of default entries on a file''.
# file: poentaro1
# owner: fletcher
# group: tourney
user::rw-
user:archer:r--
user:bowman:r--
group::rw-
group:judges:r--
class:rw-
other:---
Effect of default entries on a file
If the newly created file is a directory, the same ACL
entries are generated, but in addition the default
entries themselves are also placed in the ACL, as shown in
``Effect of default entries on a directory''.
# file: subpoento
# owner: fletcher
# group: tourney
user::rw-
user:archer:r--
user:bowman:r--
group::rw-
group:judges:r--
class:rw-
other:---
default:user:archer:r--
default:user:bowman:r--
default:group:judges:r--
Effect of default entries on a directory
Whenever a file is created, the system initializes an ACL for the file that contains 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 may be added by the user, or as a result of default entries specified on the parent directory.
The getacl(C) command reports the entries in the ACL. As indicated, each ACL has at least four entries, one each corresponding to the file mode permissions for owner, group, class, and other.
File permission bits for user and group are translated into special cases of these entries:
junk
owned by
user_1
in
group_1
whose permission mode bits are
-rw-r--r--:
If
user_2
and
user_3
and
group_2
are added to the ACL by using the
setacl(C)
command,
getacl would produce the following output:
$ getacl junk
# file: junk
# owner: user_1
# group: group_1
user::rw-
user:user_2:r--
user:user_3:r--
group::r--
group:group_2:r--
class:r--
other:r--
The mode bits on the ACL class entry are significant. The class entry mode bits are determined by the group mode bits for the file. Therefore, the group entry for the owning group and the class entry in the basic ACL are identical. When only a basic ACL exists for the file, you can think of the group and class bits as being the same. Once additional users and groups are added to the ACL, the owning group bits take on a separate identity from the class bits. If the chmod command is invoked to modify DAC permission bits when additional ACL entries exist, it effectively modifies the owner, class, and other mode bits. Please note that in the case of the DAC group permission bits, it is the class bits that are modified and not the owning group bits in the ACL entry. The only way to change ACL entries (except for the ones representing owner and other) is by using the setacl command.
If you are user_1 (the owner of the file junk used in examples earlier in this section), you can provide read access for junk to an additional user by adding an entry to the ACL naming that user and specifying read access. You do this with the setacl(C) command. For example, the following command gives user archer read-only access to the file:
setacl -r -m u:archer:r-- junkThe -m option indicates that you are adding an entry to the ACL. The -r automatically recalculates the class entry for you, so that any permissions that you specify will actually be granted.
You can add group-specific entries in just the same way. For example, to grant read and write access to everyone in the group judges, type the following:
setacl -r -m g:judges:rw- junkThe -m (modify) option can be used to change an existing entry as well as add a new one. If an entry already exists for the specified user or group, the permissions for that entry are set to the values specified on the command line.
There is also a -d option, to delete an entry. When the -d option is specified, you do not specify any permissions in the ACL entry. For example, the following command deletes an entry for the group judges:
setacl -r -d g:judges junkAny number of entries may be added using the -m option.
If you are adding or changing several entries, you will probably want to use a different procedure. You can save the ACL to a file, edit it, adding, changing, or deleting entries to produce whatever ACL you want, and then apply this new ACL to the file. For example, you could save the ACL to a file with this command:
getacl junk > junk.aclThen you could edit it so that it appeared as in ``A complex ACL''.
A complex ACL
This ACL can now be applied to the file by using the -f option of the setacl command as follows:
setacl -r -f junk.acl junk
In this example several changes have been made. While before the ACL entries only granted access to people, now they are also used to deny access as well. Note specifically the entries for user user_4 and group group_4.
ACLs are implemented through the Veritas filesystem type, vxfs. See ``Managing the VxFS filesystem'' for more information.