[ Previous | Next | Contents | Glossary | Home | Search ]
AIX Version 4.3 System User's Guide: Operating System and Devices

Access Control Lists

Access control is composed of protected information resources that specify who can be granted access to such resources. The operating system allows for need-to-know or discretionary security. The owner of an information resource can grant other users read or write access rights for that resource. A user who is granted access rights to a resource can transfer those rights to other users. This security allows for user-controlled information flow in the system; the owner of an information resource defines the access permissions to the object.

Users have user-based access only to the objects they own. Typically, users receive either the group permissions or the default permissions for a resource. The major task in administering access control is to define the group memberships of users, because these memberships determine the users' access rights to the files they do not own.

Access control lists (ACLs) increase the quality of file access controls by adding extended permissions that modify the base permissions assigned to individuals and groups. With extended permissions, you can permit or deny file access to specific individuals or groups without changing the base permissions.

Note: The access control list for a file cannot exceed one memory page (approximately 4096 bytes) in size.

Access control lists are maintained by the aclget, acledit, and the aclput commands.

Although the chmod command in numeric mode (with octal notations) can set base permissions and attributes, the chmod subroutine, which the command calls, disables extended permissions. If you use the numeric mode of the chmod command on a file that has an ACL, extended permissions are disabled. The symbolic mode of the chmod command does not disable extended permissions. For information on numeric and symbolic mode, refer to the chmod command.

Base Permissions

Base permissions are the traditional file access modes assigned to the file owner, file group, and other users. The access modes are: read (r), write (w), and execute/search (x).

In an access control list, base permissions are in the following format, with the Mode parameter expressed as rwx (with a dash replacing each unspecified permission):

base permissions: 
   owner(name): Mode
   group(group): Mode
   others: Mode

Attributes

Three attributes can be added to an access control list: setuid (SUID), setgid (SGID), and savetext (SVTX). These attributes are in the following format:

attributes: SUID, SGID, SVTX 

Extended Permissions

Extended permissions give the owner of a file the ability to define access to that file more precisely. Extended permissions modify the base file permissions (owner, group, others) by permitting, denying, or specifying access modes for specific individuals, groups, or user and group combinations.

The permit, deny, and specify keywords are defined as follows:

permit Grants the user or group the specified access to the file.
deny Restricts the user or group from using the specified access to the file.
specify Precisely defines the file access for the user or group.

If a user is denied a particular access by either a deny or a specify keyword, no other entry can override that access denial.

The enabled keyword must be specified in the access control list (ACL) for the extended permissions to take effect. The default value is the disabled keyword.

In an ACL, extended permissions are in the following format:

extended permissions: 
  enabled | disabled
    permit   Mode  UserInfo...: 
    deny     Mode  UserInfo...:
    specify  Mode  UserInfo...:

Use a separate line for each permit, deny, or specify entry. The Mode parameter is expressed as rwx (with a dash replacing each unspecified permission). The UserInfo parameter is expressed as u:UserName , or g:GroupName , or a comma-separated combination of u:UserName and g:GroupName .

Note: If more than one user name is specified in an entry, that entry cannot be used in an access control decision, because a process has only one user ID.

Access Control List Example

The following is an example of an ACL:

attributes: SUID
base permissions:
      owner(frank):  rw-
      group(system): r-x
      others: ---
extended permissions:
      enabled
        permit  rw-  u:dhs
        deny    r--  u:chas, g:system
        specify r--  u:john, g:gateway, g:mail
        permit  rw-  g:account, g:finance

The parts of the ACL and their meanings are the following:

Access Authorization

Managing access rights is the responsibility of the owner of the information resource. Resources are protected by permission bits, which are included in the mode of the object. The permission bits define the access permissions granted to the owner of the object, the group of the object, and for the others default class. The operating system supports three different modes of access (read, write, and execute) that can be granted separately.

When a user logs in to an account (using the login or su commands), the user IDs and group IDs assigned to that account are associated with the user's processes. These IDs determine the access rights of the process.

For files, directories, named pipes, message queues, shared memory segments, semaphores, and devices (special files), access is authorized as follows:

A process with a user ID of 0 is known as a root user process. These processes are generally allowed all access permissions. But if a root user process requests execute permission for a program, access is granted only if execute permission is granted to at least one user.

The identifier list of an ACL matches a process if all identifiers in the list match the corresponding type of effective identifier for the requesting process. A USER-type identifier matched is equal to the effective user ID of the process, and a GROUP-type identifier matches if it is equal to the effective group ID of the process or to one of the supplementary group IDs. For instance, an ACE with an identifier list such as:

USER:fred, GROUP:philosophers, GROUP:yankee_fans

would match a process with an effective user ID of fred and a group set of:

philosophers, philanthropists, yankee_fans, good_sports

but would not match for a process with an effective user ID of fred and a group set of:

philosophers, iconoclasts, redsox_fans, poor_sports

Note that an ACE with an identifier list of the following would match for both processes:

USER:fred, GROUP:philosophers

In other words, the identifier list in the ACE functions is a set of conditions that must hold for the specified access to be granted.

All access permission checks for these objects are made at the system call level when the object is first accessed. Since SVIPC objects are accessed statelessly, checks are made for every access. For objects with file system names, it is necessary to be able to resolve the name of the actual object. Names are resolved either relatively (to the process' working directory) or absolutely (to the process' root directory). All name resolution begins by searching one of these.

The discretionary access control mechanism allows for effective control of access to information resources and provides for separate protection of the confidentiality and integrity of the information. Owner-controlled access control mechanisms are only as effective as users make them. All users must understand how access permissions are granted and denied and how these are set.

Displaying Access Control Information (aclget Command)

You can display the access control information of a file with the aclget command. The information that you view includes attributes, base permissions, and extended permissions.

For example, to display the access control information for the status file, enter:

aclget status

The access control information that displays includes a list of attributes, base permissions, and extended permissions. For an example, see Access Control List Example .

For example, to save the access control information of the plans file in the acl1 file to edit and use later, enter:

aclget -o acl1 plans 

See the aclget command in the AIX Version 4.3 Commands Reference for the exact syntax.

Setting Access Control Information (aclput Command)

You can set the access control information of a file with the aclput command.

Note: The access control list for a file cannot exceed one memory page (approximately 4096 bytes) in size.

For example, to set the access control information for the status file with information stored in the acldefs file, enter:

aclput -i acldefs status

For example, to set the access control information for the status file with the same information used for the plans file, enter:

aclget plans | aclput status

See the aclput command in the AIX Version 4.3 Commands Reference for the exact syntax.

Editing Access Control Information (acledit Command)

You can change the access control information of a file with the acledit command. The command displays the current access control information and lets the file owner change it. Before making any changes permanent, the command asks if you want to proceed.

Note: The EDITOR environment variable must be specified with a complete path name; otherwise, the acledit command will fail.

The access control information that displays includes a list of attributes, base permissions, and extended permissions. For an example, see Access Control List Example .

For example, to edit the access control information of the plans file, enter:

acledit plans

See the acledit command in the AIX Version 4.3 Commands Reference for the exact syntax.


[ Previous | Next | Contents | Glossary | Home | Search ]