aclv man page on HP-UX

Man page or keyword search:  
man Server   10987 pages
apropos Keyword Search (all sections)
Output format
HP-UX logo
[printable version]

aclv(5)								       aclv(5)

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

DESCRIPTION
       Access  control lists (ACLs) are a key enforcement mechanism of discre‐
       tionary 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 accom‐
       plished 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 discre‐
       tionary 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	 secu‐
       rity,  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 (ordi‐
		      nary files, directories, special files, FIFOs, etc.) and
		      inter-process  communication (IPC) features (shared mem‐
		      ory, 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
		      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  sub‐
		      ject  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-spe‐
		      cific 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  sym‐
       bolic 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 per‐
       mission.

   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 fur‐
       ther  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 lim‐
       ited 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
       directories  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 follow‐
       ing 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) com‐
       mand  and the getaccess(2) system call.	Files with certain ACL proper‐
       ties 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_basemode	 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 per‐
	       missions 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  cor‐
       rectly.	 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 reference
       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),
       privgrp(4), acl(5).

								       aclv(5)
[top]

List of man pages available for HP-UX

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net