SEARCH
NEW RPMS
DIRECTORIES
ABOUT
FAQ
VARIOUS
BLOG
DONATE


YUM REPOSITORY

 
 

MAN page from Trustix acl-2.2.28-2tr.i586.rpm

ACL

Section: File Formats (5)
Index
BSD mandoc
Linux ACL 

NAME

acl - Access Control Lists 

DESCRIPTION

This manual page describes POSIX Access Control Lists, which are used todefine more fine-grained discretionary access rights for files anddirectories. 

ACL TYPES

Every object can be thought of as having associated with it an ACL thatgoverns the discretionary access to that object; this ACL is referred toas an access ACL. In addition, a directory may have an associated ACLthat governs the initial access ACL for objects created within thatdirectory; this ACL is referred to as a default ACL. 

ACL ENTRIES

An ACL consists of a set of ACL entries. An ACL entry specifies theaccess permissions on the associated object for an individual user or agroup of users as a combination of read, write and search/executepermissions.

An ACL entry contains an entry tag type, an optional entry tagqualifier, and a set of permissions.We use the term qualifier to denote the entry tag qualifier of an ACL entry.

The qualifier denotes the identifier of a user or a group, for entrieswith tag types of ACL_USER or ACL_GROUP, respectively. Entries with tagtypes other than ACL_USER or ACL_GROUP have no defined qualifiers.

The following entry tag types are defined:

ACL_USER_OBJ
The ACL_USER_OBJ entry denotes access rights for the file owner.
ACL_USER
ACL_USER entries denote access rights for users identified bythe entry's qualifier.
ACL_GROUP_OBJ
The ACL_GROUP_OBJ entry denotes access rights for the file group.
ACL_GROUP
ACL_GROUP entries denote access rights for groups identified bythe entry's qualifier.
ACL_MASK
The ACL_MASK entry denotes the maximum access rights that can be grantedby entries of type ACL_USER, ACL_GROUP_OBJ, or ACL_GROUP.
ACL_OTHER
The ACL_OTHER entry denotes access rights for processesthat do not match any other entry in the ACL.

When an access check is performed, the ACL_USER_OBJ and ACL_USER entriesare tested against the effective user ID. The effective group ID, aswell as all supplementary group IDs are tested against the ACL_GROUP_OBJand ACL_GROUP entries. 

VALID ACLs A valid ACL contains exactly one entry with each of the ACL_USER_OBJ,

ACL_GROUP_OBJ, and ACL_OTHER tag types. Entries with ACL_USER andACL_GROUP tag types may appear zero or more times in an ACL. An ACL thatcontains entries of ACL_USER or ACL_GROUP tag types must containexactly one entry of the ACL_MASK tag type. If an ACL contains noentries of ACL_USER or ACL_GROUP tag types, the ACL_MASK entry isoptional.

All user ID qualifiers must be unique among all entries ofACL_USER tag type, and all group IDs must be unique among all entries ofACL_GROUP tag type.


  TheFn acl_get_filefunction returns an ACL with zero ACL entries as the default ACL of adirectory, if the directory is not associated with a default ACL. TheFn acl_set_filefunction also accepts an ACL with zero ACL entries as a valid default ACL fordirectories, denoting that the directory shall not be associated with adefault ACL. This is equivalent to using theFn acl_delete_def_filefunction. 

CORRESPONDENCE BETWEEN ACL ENTRIES AND FILE PERMISSION BITS

The permissions defined by ACLs are a superset of the permissionsspecified by the file permission bits. The permissions defined forthe file owner correspond to the permissions of the ACL_USER_OBJ entry.The permissions defined for the file group correspond to the permissionsof the ACL_GROUP_OBJ entry, if the ACL has no ACL_MASK entry. If the ACLhas an ACL_MASK entry, then the permissions defined for the file groupcorrespond to the permissions of the ACL_MASK entry. The permissionsdefined for the other class correspond to the permissions of theACL_OTHER_OBJ entry.

Modification of the file permission bits results in the modification ofthe permissions in the associated ACL entries. Modification of thepermissions in the ACL entries results in the modification of the filepermission bits. 

OBJECT CREATION AND DEFAULT ACLs The access ACL of a file object is initialized when the object is

created with any of theFn creat ,Fn mkdir ,Fn mknod ,Fn mkfifo ,orFn openfunctions. If a default ACL is associated with a directory, themodeparameter to the functions creating file objects and the default ACL ofthe directory are used to determine the ACL of the new object:

  1. The new object inherits the default ACL of the containing directoryas its access ACL.
  2. The access ACL entries corresponding to the file permission bits aremodified so that they contain no permissions that are notcontained in the permissions specified by themodeparameter.

If no default ACL is associated with a directory, themodeparameter to the functions creating file objects and the file creationmask (seeumask(2))are used to determine the ACL of the new object:

  1. The new object is assigned an access ACL containing entries of tag typesACL_USER_OBJ, ACL_GROUP_OBJ, and ACL_OTHER. The permissions of theseentries are set to the permissions specified by the file creation mask.
  2. The access ACL entries corresponding to the file permission bits aremodified so that they contain no permissions that are notcontained in the permissions specified by themodeparameter.

 

ACCESS CHECK ALGORITHM

A process may request read, write, or execute/search access to a file objectprotected by an ACL. The access check algorithm determines whether access tothe object will be granted.

  1. If the effective user ID of the process matches the user ID of the file object owner,then

    ifthe ACL_USER_OBJ entry contains the requested permissions, access is granted,

    elseaccess is denied.

  2. else ifthe effective user ID of the process matches the qualifier of any entryof type ACL_USER,then

    ifthe matching ACL_USER entry and the ACL_MASK entry contain the requestedpermissions, access is granted,

    elseaccess is denied.

  3. else ifthe effective group ID or any of the supplementary group IDs of the processmatch the file group or the qualifier of any entry of type ACL_GROUP, then

    ifthe ACL contains an ACL_MASK entry,thenifthe ACL_MASK entry and any of the matching ACL_GROUP_OBJ or ACL_GROUP entriescontainthe requested permissions, access is granted,

    elseaccess is denied.

    else(note that there can be no ACL_GROUP entries without an ACL_MASK entry)ifthe ACL_GROUP_OBJ entry contains the requested permissions,access is granted,

    elseaccess is denied.

  4. else ifthe ACL_OTHER entry contains the requested permissions, access is granted.
  5. elseaccess is denied.

 

ACL TEXT FORMS

A long and a short text form for representing ACLs is defined. In both forms, ACL entries are represented as three colon separated fields: an ACL entry tag type, an ACL entry qualifier, and the discretionary access permissions. The first field contains one of the following entry tag type keywords:

user
AuserACL entry specifies the access granted to either the file owner (entry tagtype ACL_USER_OBJ) or a specified user (entry tag type ACL_USER).
group
AgroupACL entry specifies the access granted to either the file group (entry tagtype ACL_GROUP_OBJ) or a specified group (entry tag type ACL_GROUP).
mask
AmaskACL entry specifies the maximum access which can be granted by any ACLentry except theuserentry for the file owner and theotherentry (entry tag type ACL_MASK).
other
An other ACL entry specifies the access granted to any process that doesnot match anyuserorgroupACL entries (entry tag type ACL_OTHER).

The second field contains the user or group identifier of the user orgroup associated with the ACL entry for entries of entry tag type ACL_USERor ACL_GROUP, and is empty for all other entries. A user identifier canbe a user name or a user ID number in decimal form. A group identifier canbe a group name or a group ID number in decimal form.

The third field contains the discretionary access permissions. The read,write and search/execute permissions are represented by ther w andxcharacters, in this order. Each of these characters is replaced by the-character to denote that a permission is absent in the ACL entry.When converting from the text form to the internal representation,permissions that are absent need not be specified.

White space is permitted at the beginning and end of each ACL entry, andimmediately before and after a field separator (the colon character). 

LONG TEXT FORM

The long text form contains one ACL entry per line. In addition, anumber sign( # may start a comment that extends until the end of the line. If anACL_USER, ACL_GROUP_OBJ or ACL_GROUP ACL entry contains permissions thatare not also contained in the ACL_MASK entry, the entry is followed by anumber sign, the string lqeffective:rq, and the effective accesspermissions defined by that entry. This is an example of the long textform:
user::rw-user:lisa:rw-         #effective:r--group::r--group:toolies:rw-     #effective:r--mask::r--other::r--
 

SHORT TEXT FORM

The short text form is a sequence of ACL entries separated by commas,and is used for input. Comments are not supported. Entry tag typekeywords may either appear in their full unabbreviated form, or in theirsingle letter abbreviated form. The abbreviation foruserisu the abbreviation forgroupisg the abbreviation formaskism and the abbreviation forotheriso The permissions may contain at most one each of the following charactersin any order:r w x These are examples of the short text form:
u::rw-,u:lisa:rw-,g::r--,g:toolies:rw-,m::r--,o::r--g:toolies:rw,u:lisa:rw,u::wr,g::r,o::r,m::r
 

RATIONALE

IEEE 1003.1e draft 17 defines Access Control Lists that include entriesof tag type ACL_MASK, and defines a mapping between file permission bitsthat is not constant. The standard working group defined this relativelycomplex interface in order to ensure that applications that are compliantwith IEEE 1003.1 (lqPOSIX.1rq) will still function as expected onsystems with ACLs. The IEEE 1003.1e draft 17 contains the rationale forchoosing this interface in section B.23.  

CHANGES TO THE FILE UTILITIES

On a system that supports ACLs, the file utilitiesls(1),cp(1),andmv(1)change their behavior in the following way:

  • For files that have a default ACL or an access ACL that contains more thanthe three required ACL entries, thels(1)utility in the long form produced byls -ldisplays a plus sign( + after the permission string.
  • If the-pflag is specified, thecp(1)utility also preserves ACLs.If this is not possible, a warning is produced.

  •   Themv(1)utility always preserves ACLs. If this is not possible, a warning is produced.

The effect of thechmod(1)utility, and of thechmod(2)system call, on the access ACL is described inSx CORRESPONDENCE BETWEEN ACL ENTRIES AND FILE PERMISSION BITS . 

STANDARDS

The IEEE 1003.1e draft 17 (lqPOSIX.1erq) document describes severalsecurity extensions to the IEEE 1003.1 standard. While the work on1003.1e has been abandoned, many UNIX style systems implement parts ofPOSIX.1e draft 17, or of earlier drafts.

Linux Access Control Lists implement the full set of functions andutilities defined for Access Control Lists in POSIX.1e, and severalextensions. The implementation is fully compliant with POSIX.1e draft17; extensions are marked as such.The Access Control List manipulation functions are defined inthe ACL library (libacl, -lacl). The POSIX compliant interfaces aredeclared in the<sys/acl.h>header. Linux-specific extensions to these functions are declared in the<acl/libacl.h>header. 

SEE ALSO

chmod(1),creat(2),getfacl(1),ls(1),mkdir(2),mkfifo(2),mknod(2),open(2),setfacl(1),stat(2),umask(1) 

POSIX 1003.1e DRAFT 17

http://www.guug.de/~winni/posix.1e/download.html 

POSIX 1003.1e FUNCTIONS BY CATEGORY

ACL storage management
acl_dup3,acl_free3,acl_init3
ACL entry manipulation
acl_copy_entry3,acl_create_entry3,acl_delete_entry3,acl_get_entry3,acl_valid3

acl_add_perm3,acl_calc_mask3,acl_clear_perms3,acl_delete_perm3,acl_get_permset3,acl_set_permset3

acl_get_qualifier3,acl_get_tag_type3,acl_set_qualifier3,acl_set_tag_type3

ACL manipulation on an object
acl_delete_def_file3,acl_get_fd3,acl_get_file3,acl_set_fd3,acl_set_file3
ACL format translation
acl_copy_entry3,acl_copy_ext3,acl_from_text3,acl_to_text3,acl_size3

 

POSIX 1003.1e FUNCTIONS BY AVAILABILITY

The first group of functions is supported on most systems with POSIX-likeaccess control lists, while the second group is supported on fewer systems.For applications that will be ported the second group is best avoided.

acl_delete_def_file3,acl_dup3,acl_free3,acl_from_text3,acl_get_fd3,acl_get_file3,acl_init3,acl_set_fd3,acl_set_file3,acl_to_text3,acl_valid3

acl_add_perm3,acl_calc_mask3,acl_clear_perms3,acl_copy_entry3,acl_copy_ext3,acl_copy_int3,acl_create_entry3,acl_delete_entry3,acl_delete_perm3,acl_get_entry3,acl_get_permset3,acl_get_qualifier3,acl_get_tag_type3,acl_set_permset3,acl_set_qualifier3,acl_set_tag_type3,acl_size3 

LINUX EXTENSIONS

These non-portable extensions are available on Linux systems.

acl_check3,acl_cmp3,acl_entries3,acl_equiv_mode3,acl_error3,acl_extended_fd3,acl_extended_file3,acl_from_mode3,acl_get_perm3,acl_to_any_text3 

AUTHOR

Andreas Gruenbacher, <a.gruenbacherAATTbestbits.at>


 

Index

NAME
DESCRIPTION
ACL TYPES
ACL ENTRIES
VALID ACLs
CORRESPONDENCE BETWEEN ACL ENTRIES AND FILE PERMISSION BITS
OBJECT CREATION AND DEFAULT ACLs
ACCESS CHECK ALGORITHM
ACL TEXT FORMS
LONG TEXT FORM
SHORT TEXT FORM
RATIONALE
CHANGES TO THE FILE UTILITIES
STANDARDS
SEE ALSO
POSIX 1003.1e DRAFT 17
POSIX 1003.1e FUNCTIONS BY CATEGORY
POSIX 1003.1e FUNCTIONS BY AVAILABILITY
LINUX EXTENSIONS
AUTHOR

This document was created byman2html,using the manual pages.