*nix Documentation Project
·  Home
 +   man pages
·  Linux HOWTOs
·  FreeBSD Tips
·  *niX Forums

  man pages->HP-UX 11i man pages -> aclv (5)              


 aclv(5)                                                             aclv(5)

 NAME    [Toc]    [Back]
      aclv - introduction to JFS access control lists (ACLs)

 DESCRIPTION    [Toc]    [Back]
      Access control lists (ACLs) are a key enforcement mechanism of
      discretionary access control (see Definitions below), for specifying
      access to files by users and groups more selectively than traditional
      HP-UX mechanisms allow.

      HP-UX already enables non-privileged users or processes, such as file
      owners, to allow or deny other users access to files and other objects
      on a ``need to know'' basis, as determined by their user and/or group
      identity (see passwd(4) and group(4)).  This level of control is
      accomplished by setting or manipulating a file's permission bits to
      grant or restrict access by owner, group, and others (see chmod(2)).

      ACLs offer a greater degree of selectivity than permission bits.  ACLs
      allow the file owner or superuser to permit or deny access to a list
      of users and groups other than the file owner and owning group.

      ACLs are supported as a superset of the UNIX operating system
      discretionary access control (DAC) mechanism for files, but not for
      other objects such as inter-process communication (IPC) objects.

      This manual page describes ACLs as implemented on JFS file systems
      only.  See acl(5) for a description of ACLs in HFS file systems.

    Definitions    [Toc]    [Back]
      Because control of access to data is a key concern of computer
      security, we provide the following definitions, based on those of the
      Department of Defense Trusted Computer System Evaluation Criteria, to
      explain further both the concepts of access control and its relevance
      to HP-UX security features:

      access         ``A specific type of interaction between a subject and
                     an object that results in the flow of information from
                     one to the other.'' Subjects include ``persons,
                     processes, or devices that cause information to flow
                     among objects or change the system state.'' Objects
                     include files (ordinary files, directories, special
                     files, FIFOs, etc.) and inter-process communication
                     (IPC) features (shared memory, message queues,
                     semaphores, sockets).

      access control list (ACL)
                     An access control list is a set of (user|group, mode)
                     entries associated with a file that specify permissions
                     for all possible user-IDs and/or group-IDs.

      access control list (ACL) entry
                     An entry in an ACL that specifies access rights for a

 Hewlett-Packard Company            - 1 -   HP-UX 11i Version 2: August 2003

 aclv(5)                                                             aclv(5)

                     file's owner, owning group, group class, additional
                     user, additional group, or all others.

      change permission
                     The right to alter DAC information (permission bits or
                     ACL entries).  Change permission is granted to object
                     (file) owners and to privileged users.

      discretionary access control (DAC)
                     ``A means of restricting access to objects based on the
                     identity of subjects and/or groups to which they
                     belong.  The controls are discretionary in the sense
                     that a subject with a certain access permission is
                     capable of passing that permission (perhaps indirectly)
                     to any other subject.''

      mode           Three bits in each ACL entry which represent read,
                     write, and execute/search permissions.  These bits may
                     exist in addition to the 16 mode bits associated with
                     every file in the file system (see glossary(9)).

      privilege      The ability to ignore access restrictions and change
                     restrictions imposed by security policy and implemented
                     in an access control mechanism.  In HP-UX, superusers
                     and members of certain groups (see privgrp(4)) are the
                     only privileged users.

      restrictive versus permissive
                     An individual ACL entry is considered restrictive or
                     permissive, depending on context.  Restrictive entries
                     deny a user and/or group access that would otherwise be
                     granted by less-specific base or optional ACL entries
                     (see below).  Permissive entries grant a user and/or
                     group access that would otherwise be denied by lessspecific
 base or optional ACL entries.

    Access Control List Entries    [Toc]    [Back]
      An access control list (ACL) consists of a set of one-line entries
      associated with a file that specify permissions.  Each entry specifies
      for one user-ID or group-ID a set of access permissions, including
      read, write, and execute/search.

      To help understand the relationship between access control lists and
      traditional file permissions, consider the following file and its

           -rwxr-xr--   james   admin   datafile

           The file owner is user james.
           The file's group is admin.

 Hewlett-Packard Company            - 2 -   HP-UX 11i Version 2: August 2003

 aclv(5)                                                             aclv(5)

           The name of the file is datafile.
           The file owner permissions are rwx.
           The file group permissions are r-x.
           The file other permissions are r--.

      In an ACL, user and group IDs can be represented by names or numbers,
      found in /etc/passwd.

    ACL Notation    [Toc]    [Back]
      Supported commands that manage JFS ACLs recognize the following
      symbolic representation:





      An ACL entry prefixed with d: or default:, can only occur in a
      directory's ACL, and it indicates that the remainder of the entry is
      not to be used in determining the access rights to the directory, but
      is instead to be applied to any files or subdirectories created in the
      directory (see ACL Inheritance, below).

      The uid and gid fields contain either numeric user or group IDs, or
      their corresponding character strings from /etc/passwd or /etc/group.
      The perm field indicates access permission either in symbolic form, as
      a combination of r, w, x and -, or in numeric form, as an octal value
      of 0 through 7 representing the sum of 4 for read permission, 2 for
      write permission and 1 for execute permission.

    Base ACL Entries    [Toc]    [Back]
      When a file is created, four base access control list entries are
      mapped from the file's access permission bits to match a file's owner
      and group and its traditional permission bits.  This is known as a
      ''minimal ACL''.  Base ACL entries can be changed by the chmod(2) and
      acl(2) system calls.

      u::perm   Base ACL entry for the file's owner

      g::perm   Base ACL entry for the file's group

      c::perm   Base ACL entry for the file's group class

      o::perm   Base ACL entry for others

      When an ACL is minimal, i.e., it has no optional ACL entries (see next
      section), then the group and class permissions are exactly equal.

 Hewlett-Packard Company            - 3 -   HP-UX 11i Version 2: August 2003

 aclv(5)                                                             aclv(5)

    Optional ACL entries    [Toc]    [Back]
      Optional access control list entries contain additional access control
      information, which the user can set with the acl(2) system call to
      further allow or deny file access.  Up to thirteen optional ACL
      entries can be specified.

      For example, the following optional access control list entries can be
      associated with our file:

      u:mary:rwx               Grant read, write, and execute access to user

      user:george:---          Deny any access to user george.

      g:writers:rw-            Grant read and write access to members of
                               group writers.

    Class Entries    [Toc]    [Back]
      In an ACL that contains more than one user entry and/or more than one
      group 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, then 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 acts as a upper bound for
      file permissions.

      When an ACL contains more than one user and/or group entry, the
      collection of additional user and group entries are referred to as the
      groupclass 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 entry will no
      longer necessarily equal the value of the permission for the owning
      group as reported by ls -l.  This feature is useful because it means
      that the chmod(1) command can usefully affect the permissions of a
      file that has additional ACL entries.

    ACL Uniqueness    [Toc]    [Back]
      Entries are unique in each ACL.  There can only be one of each type of
      base entry, and one entry for any given user or group ID.  Likewise,
      there can only be one of each type of default base entry, and one
      default entry for any given user or group ID.

    ACL Inheritance    [Toc]    [Back]
      When a directory's ACL contains default entries, those entries are not
      used in determining access to the directory itself.  Instead, every
      time a file is created in the directory, the directory's default ACL
      entries are added as non-default ACL entries to the new file.

 Hewlett-Packard Company            - 4 -   HP-UX 11i Version 2: August 2003

 aclv(5)                                                             aclv(5)

      For example, suppose the directory /a has the following ACL, as
      reported by getacl(1):

           # file: /a
           # owner: alpha
           # group: uno

      Then, any new file created in /a would have its ACL initialized using
      a combination of the creator's umask (e.g., 022) and /a's default ACL
      entries as follows:

           # file: /a/file
           # owner: creator_uid
           # group: creator_gid

      When a new subdirectory is created, the parent directory's default ACL
      entries are added to the new subdirectory twice, first as its nondefault
 ACL entries, and second as the subdirectory's default ACL
      entries.  In this way, default ACLs propagate downward as trees of
      directories are created.  If the file created in the previous example
      were instead a directory, its ACL would appear as follows:

           # file: /a/dir
           # owner: creator_uid
           # group: creator_gid

 Hewlett-Packard Company            - 5 -   HP-UX 11i Version 2: August 2003

 aclv(5)                                                             aclv(5)


    Access Check Algorithm    [Toc]    [Back]
      To determine the permission granted to an accessing process's
      effective user ID (EGID) and effective group ID (EGID), respectively,
      the following checks are made, in the following order:

           If the EUID of the process is the same as the owner of the file,
           grant the permissions specified in the user:: entry.

           If the EUID matches the UID specified in one of the additional
           user:uid: entries, grant the permissions specified in that entry,
           bitwise-ANDed with the permissions specified in the class entry.

           If the EGID of the process is the same as the owning group of the
           file, grant the permissions specified in the group:: entry.

           If the EGID matches the UID specified in one of the additional
           group:gid: entries, grant the permissions specified in that
           entry, bitwise-ANDed with the permissions specified in the class

           Otherwise, grant the permissions specified in the other entry.

      Once access rights have been determined by one of the above checks,
      the subsequent checks in the list are not performed.

    ACL Operations Supported    [Toc]    [Back]
      ACLs may be set, retrieved or counted, via the acl(2) system call.
      ACLs may be set or modified using the setacl(1) command, and may be
      retrieved using the getacl(1) command.  The permissions granted to a
      particular user or group ID may be determined via the getaccess(1)
      command and the getaccess(2) system call.  Files with certain ACL
      properties may be located using the -aclv option of find(1).

    ACL Interaction with stat(2), chmod(2), and chown(2)
      stat    The st_mode field summarizes the caller's access rights to the
              file.  It differs from file permission bits only if the file
              has one or more optional entries applicable to the caller.
              The st_basemode field provides the file's actual permission
              bits.  The st_aclv field indicates the presence of optional
              ACL entries in the file's ACL.

              The st_mode field contains a user-dependent summary, so that
              programs ignorant of ACLs that use stat(2) and chmod(2) are
              more likely to produce expected results, and so that stat(2)
              provides reasonable information about remote files over NFS.
              The st_basemode and st_aclv fields are useful only for local

 Hewlett-Packard Company            - 6 -   HP-UX 11i Version 2: August 2003

 aclv(5)                                                             aclv(5)

      chmod   Setting the group permission bits via chmod(2) system call
              affects the file's class entry, which would in turn affect the
              permissions granted by additional user:uid: and group:gid:
              entries.  In particular, using chmod(2) to set a file's
              permission bits to all zeroes removes all access to the file,
              regardless of permissions granted by any additional user:uid:
              or group:gid: entries.

      chown   When a file's owner or owning group are changed via chown(2)
              to a UID or GID which have existing user:uid: or group:gid:
              entries, those entries are not removed from the ACL, but they
              are rendered moot, because the user:: or group:: entries take

 HEADERS    [Toc]    [Back]
    Header <sys/acl.h>
      The <sys/aclv.h> header file defines the following constants to govern
      the numbers of entries per ACL:

           NACLVENTRIES          maximum number of entries per ACL,
                                 including base entries
           NACLBASE              number of base entries

      The ACL structure struct acl is also defined, and includes the
      following members:

           int a_type;       /* type of entry */
           uid_t a_id;       /* group ID */
           ushort a_perm;    /* see <unistd.h> */

      The <sys/aclv.h> header also defines the set of valid values for the
      a_type field, as well as the valid values for the cmd argument to the
      acl(2) system call.

    Header <sys/getaccess.h>
      The <sys/getaccess.h> header defines constants for use with

      Special parameter values for uid:

      UID_EUID   use effective user ID
      UID_RUID   use real user ID
      UID_SUID   use saved user ID

      Special parameter values for ngroups:

      NGROUPS_EGID        process's effective gid
      NGROUPS_RGID        process's real gid
      NGROUPS_SGID        process's saved gid
      NGROUPS_SUPP        process's supplementary groups only
      NGROUPS_EGID_SUPP   process's eff gid plus supp groups

 Hewlett-Packard Company            - 7 -   HP-UX 11i Version 2: August 2003

 aclv(5)                                                             aclv(5)

      NGROUPS_RGID_SUPP   process's real gid plus supp groups
      NGROUPS_SGID_SUPP   process's saved gid plus supp groups

 WARNINGS    [Toc]    [Back]
      ACLs cannot be used to restrict the superuser's access.

      Most, but not all, supported utilities are able to handle ACLs
      correctly.  However, only the fbackup(1M) and frecover(1M) file
      archive utilities handle access control lists properly.  When using
      programs (such as archive programs ar(1), cpio(1), ftio(1), tar(1),
      and dump(1M)) unable to handle ACLs on files with optional ACL
      entries, note the Access Control List information included on their
      respective reference pages, to avoid loss of data.

 DEPENDENCIES    [Toc]    [Back]
      NFS  NFS does not support ACLs on remote files.  Individual manual
           entries specify the behavior of various system calls, library
           calls, and commands under these circumstances.  Be careful when
           transferring a file with optional entries over a network or when
           manipulating a remote file because optional entries may be
           silently deleted.

 AUTHOR    [Toc]    [Back]
      The access control list design described here was developed by AT&T.

 FILES    [Toc]    [Back]
      <sys/aclv.h>        Header file that supports acl(2).
      /etc/passwd         Defines user names and user and group ID values.
      /etc/group          Defines group names.

 SEE ALSO    [Toc]    [Back]
      chmod(1), cp(1), find(1), getaccess(1), getacl(1), ln(1), ls(1),
      mv(1), rm(1), setacl(1), fbackup(1M), frecover(1M), fsck(1M), fsdb(1M)
      access(2), acl(2), chmod(2), chown(2), creat(2), getaccess(2),
      mknod(2), open(2), stat(2), aclsort(3), cpacl(3), group(4), passwd(4),
      privgrp(4), acl(5).

 Hewlett-Packard Company            - 8 -   HP-UX 11i Version 2: August 2003
[ Back ]
 Similar pages
Name OS Title
lsacl HP-UX list access control lists (ACLs) of files
setacl HP-UX modify access control lists (ACLs) for files (JFS File Systems only)
getacl HP-UX list access control lists (ACLs) for files (JFS File Systems only)
swacl HP-UX view or modify the Access Control Lists (ACLs) which protect software products
chacl HP-UX add, modify, delete, copy, or summarize access control lists (ACLs) of files
acl HP-UX introduction to HFS access control lists
acl_edit HP-UX Edits or lists an object's ACLs
acl IRIX Access Control Lists
acl_db IRIX database of Access Control Lists
acl FreeBSD virtual file system access control lists
Copyright © 2004-2005 DeniX Solutions SRL
newsletter delivery service