acl - Access control list
The Tru64 UNIX ACLs are based on the POSIX P1003.6 Draft 13 standard. ACL functionality and interfaces may change as the P1003.6 standard is finalized. Traditionally, UNIX systems control a user's access to files and directories (filesystem objects) using a method of discretionary access control (DAC) normally referred to as the permission bits. By default, Tru64 UNIX systems are run using this untrusted method of DAC for filesystem objects. This default DAC defines the categories 'owning user', 'owning group', and 'other', as attributes of these objects, and associates a set of access permissions with each of the categories.
ACLs provide greater granularity of filesystem object protection than the default Tru64 UNIX DAC. The level of filesystem object protection provided by ACLs is required by trusted systems, but ACLs can be enabled separately from the other security options. This allows you to tailor your system to use only the security options that you need, instead of having to setup a fully trusted system.
With ACLs enabled, an access control list (ACL) is associated with a file or directory. The ACL is an extended file attribute stored in the file or directory's property List. The ACL provides the access permission categories normally supplied by the default DAC and also provides discretionary access permissions on individually specified users and groups. Extended in this manner, DAC is compatible with system calls such as chown(), chgrp(), chmod(), stat(), and open(), which use existing interfaces to retrieve and manipulate access permission bits.
To be granted the set of permissions associated with one of the ACL user categories above, a process "identifies" itself through its effective user ID (UID) or its set of group IDs (an effective GID with optional supplementary GIDs) as belonging to that category. Also, the permissions requested by the process must be a subset of the permissions associated with the category.
Discretionary access control with ACLs consists of an ACL initialization that accompanies object creation, DAC access checking, functions and system calls for ACL retrieval and manipulation, format conversion, validity checking, and storage management. This extended version of DAC includes the library functions, system calls, and commands for manipulating ACLs.
The following functions retrieve and manipulate ACL entries:
The following functions retrieve and manipulate fields in an ACL entry:
The following functions manage working storage for ACL manipulation:
The following functions validate and convert ACLs:
The following functions perform format conversion between external and internal representations of an ACL:
The following commands display and change the contents of an ACL: Changes an ACL on a file or directory. Displays an ACL on a file or directory.
The default access ACL is associated only with directories. It is inherited as the access ACL by all non-directory objects created within the directory containing the default access ACL. If there is no default directory ACL associated with the directory, directories that are created inherit the default access ACL as both its access and default access ACL. Otherwise, it is inherited as the default access ACL.
The default directory ACL is inherited as the access ACL for directories that are created within a directory having the default directory ACL type.
Users normally specify ACLs with the setacl command.
When a file or directory is created, the default access ACL of its parent directory automatically initializes a new ACL, as summarized in the Default ACLs section. If a default access ACL does not exist, the untrusted method of initializing an object's DAC attributes automatically applies. Briefly, this method logically ANDs the complement of a process's umask, if one exists, with the mode parameter (the permissions parameter, which is supplied by any of the object creation functions mentioned above). The result of complementation and ANDing automatically initializes permission fields associated with the required entries, as follows: The leftmost three bits set the ACL_USER_OBJ entry. The middle three bits set the ACL_GROUP_OBJ entry. The remaining three bits set the ACL_OTHER_OBJ entry.
No other ACL entries can be initialized without default access ACLs.
For a description of a process umask, see the umask(2) reference page.
If the newly created object is a directory, it inherits its access ACL from its parent directory; otherwise, its access ACL is initialized by the untrusted methods for initializing an access ACL on a file. If the parent directory has a default access ACL, the new directory inherits the parent's default ACL as its default access ACL.
A default access ACL has the same minimum required entries as an access ACL. A default access ACL may also be empty of any entries. A default ACL's entries are manipulated by the same commands and functions as access ACLs.
The default access ACL is used only to initialize ACLs and is not used by the DAC access checking mechanism to check the access on an object.
Upon object creation, an existing default access ACL is automatically copied to a new object's ACL and sets its contents. Permissions from any of the *_OBJ entries in the the default access ACL automatically interact with the object mode parameter (specified by the object creation system calls referred to earlier) as follows: The permission bits of ACL_USER_OBJ are set to the intersection of this same entry's permission bits from the default access ACL with the owner bits from the mode parameter. The permission bits of ACL_OTHER_OBJ are set to the intersection of this same entry's permission bits from the default access ACL with the other bits from the mode parameter. The permission bits of ACL_GROUP_OBJ are set to the intersection of this same entry's permission bits from the default access ACL with the group bits from the mode parameter.
DAC access checking combines untrusted file attribute information with ACLs in checking access to an object. The checking algorithm checks ACL entries in the following order, regardless of how the ACL entries are ordered:
1. ACL_USER_OBJ entry 2. ACL_USER entries 3. ACL_GROUP_OBJ entry 4. ACL_GROUP entries 5. ACL_OTHER_OBJ entry The first occurrence of a match determines which set of permissions governs a process's access to an object. For example, if a process's effective uid and gid both match entries in the ACL, the process's access is governed by the set of permissions associated with the matching UID entry in the ACL. This ordering also means, for example, that if a process's effective UID matches both ACL_USER_OBJ and a ACL_USER entry, the process's access is governed by the permissions associated with the ACL_USER_OBJ entry.
The checking algorithm is as follows: Check the process's effective UID against the UID of the owning user. If there is a match, check each of the requested permissions against the permissions of the matching ACL entry. If the requested permissions are a subset of the associated permissions, grant the request. If not, deny the request. If the process's effective UID does not match against the UID of the owning user entry, ACL_USER_OBJ, check the effective UID against the UID of every non-owning user entry, ACL_USER. If the process's effective GID or any of the supplementary GID values does not match against the GID of the owning group entry, ACL_GROUP_OBJ, check the effective GID against the GID of every non-owning group entry, ACL_GROUP. If the requested permissions are a subset of this intersection, grant the request. If not, deny the request. Finally, if neither the process's effective GID nor any of the supplementary GID values match to any of the GID values contained in any of the group entries, check each of the requested permissions against the permissions of the other entry, ACL_OTHER_OBJ. If the requested permissions are a subset of the permissions associated with the matching entry, grant the request. If not, deny the request.
NFS V2 clients make their own access decisions based on their interpretation of a file's mode bits. Based on this decision, they may allow access to data cached on the client from a previous access by another user. A file that is protected by an ACL can not reflect the correct access for all users in the access bits for the file. It may be that access that would be granted by the mode bits is actually denied explicitly by the ACL. It may also be that access that seems to be denied by the mode bits is, in fact, granted explicitly by the mode bits. The nfs-flatten-mode parameter can be used to modify the bits that exist on the server before presentation to the client.
NFS V3 clients have, in essence, an "open" protocol request that they use to defer the access decision to the server, and grants access only when they have previously made an "open" request for the same user and file.
Setting the nfs-flatten-mode parameter to the restrictive setting (1) can cause some users to be denied access to files that they should legitimately be granted access to. Setting the parameter to the permissive setting (2) can cause some users to be granted access to files that they should not be granted access to, but only for read access to data in the client cache, since any request that is sent to the server (and all write requests are supposed to be sent to the server) results in an access decision on the server denying the request. Setting the parameter to the unmodified setting (0) leaves the mode bits unmodified, possibly resulting in both inadvertent denial and granting of access, while accurately displaying the bits on the client as they would be displayed on the server.
The allowable values are:
The default value is 0.
Commands: setacl(1), chgrp(1), chmod(1), chown(1), getacl(1)
acl_add_perm(3) acl_clear_perm(3) acl_copy_entry(3) acl_copy_ext(3) acl_copy_int(3) acl_create_entry(3) acl_delete_def_fd(3) acl_delete_def_file(3) acl_delete_entry(3) acl_delete_perm(3) acl_dup(3) acl_first_entry(3) acl_free(3) acl_free_qualifier(3) acl_free_text(3) acl_from_text(3) acl_get_entry(3) acl_get_fd(3) acl_get_file(3) acl_get_permset(3) acl_get_qualifier(3) acl_get_tag_type(3) acl_init(3) acl_set_fd(3) acl_set_file(3) acl_set_permset(3) acl_set_qualifier(3) acl_set_tag_type(3) acl_size(3) acl_to_text(3) acl_valid(3)
Files: proplist(4) delim off