hpux man page for aclv

aclv(5) 							File Formats Manual							   aclv(5)

NAME
       aclv - introduction to JFS access control lists (ACLs)

DESCRIPTION
       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
       Because control of access to data is a key concern of computer security, we provide the following definitions, based on	those  of  the	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 possi-
		      ble user-IDs and/or group-IDs.

       access control list (ACL) entry
		      An  entry  in an ACL that specifies access rights for a 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 con-
		      trols 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 that 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 less-specific base or optional ACL entries.

   Access Control List Entries
       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 per-
       missions:

	      The file owner is user james.
	      The file's group is admin.
	      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

   ACL Notation
       Supported commands that manage JFS ACLs recognize the following symbolic representation:

	      [uid]

	      [gid]

       An  ACL	entry  prefixed with or can occur only 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 or The perm field indicates
       access permission either in symbolic form, as a combination of 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
       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.

       Base ACL entry for the file's owner

       Base ACL entry for the file's group

       Base ACL entry for the file's group class

       Base ACL entry for others

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

   Optional ACL entries
       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:

       Grant read, write, and execute access to user mary.

       Deny any access to user george.

       Grant read and write access to members of group writers.

   Class Entries
       In an ACL that contains more than one entry and/or more than one entry, the entry specifies the maximum permissions that can be granted	by
       any  of	the  additional and entries.  If a particular permission is not granted in the entry, then it cannot be granted by any ACL entries
       (except for the first [owner] entry and the entry).  Any permission can be denied to a particular user or group.  The entry acts as a upper
       bound for file permissions.

       When  an  ACL contains more than one and/or entry, the collection of additional and entries are referred to as the class entries, since the
       effective permission granted by any of these additional entries is limited by the entry.

       If there are additional entries in the ACL, the entry will no longer necessarily equal the value of the permission for the owning group	as
       reported  by This feature is useful because it means that the chmod(1) command can usefully affect the permissions of a file that has addi-
       tional ACL entries.

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

   ACL Inheritance
       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.

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

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

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

   Access Check Algorithm
       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 entry.

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

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

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

	      Otherwise, grant the permissions specified in the 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
       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 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_base-
	       mode and st_aclv fields are useful only for local files.

       chmod   Setting the group permission bits via chmod(2) system call affects the file's entry, which would in  turn  affect  the  permissions
	       granted	by additional and 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 or entries.

       chown   When a file's owner or owning group are changed via chown(2) to a UID or GID that has existing or entries, those  entries  are  not
	       removed from the ACL, but they are rendered moot, because the or entries take precedence.

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

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

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

       The header also defines the set of valid values for the field, as well as the valid values for the cmd argument to the acl(2) system call.

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

       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 effective gid plus supplementary groups
       NGROUPS_RGID_SUPP       process's real gid plus supplementary groups
       NGROUPS_SGID_SUPP       process's saved gid plus supplementary groups

WARNINGS
       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 unable to handle ACLs on files with optional ACL entries (such as  ar-
       chive programs ar(1), cpio(1), ftio(1), tar(1), and dump(1M)), note the Access Control List information included on their respective refer-
       ence pages to avoid loss of data.

DEPENDENCIES
       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
       The access control list design described here was developed by AT&T.

FILES
       Header file that supports
			   acl(2).

       Defines user names and user and group ID values.

       Defines group names.

SEE ALSO
       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), priv-
       grp(4), acl(5).

																	   aclv(5)