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 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
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 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.
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:
Note: More than one extended entry can be applied to a process, with restrictive modes taking precedence over permissive modes.
See the acledit command in the AIX Version 4.3 Commands Reference for the exact syntax.
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.
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.
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.
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.