Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
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 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 ob-
       jects 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, pro-
		      cesses, or devices that cause information	to flow	 among
		      objects  or  change the system state.''  Objects include
		      files (ordinary files, directories, special  files,  FI-
		      FOs,  etc.)  and	inter-process communication (IPC) fea-
		      tures (shared memory, message queues, semaphores,	 sock-
		      ets).

       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  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 re-
		      strictions 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 as-
       sociated	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 only occur in a directory's ACL,  and
       it  indicates  that the remainder of the	entry is not to	be used	in de-
       termining the access rights to the directory, but is instead to be  ap-
       plied  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 (ex-
       cept 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  ad-
       ditional	 and  entries are referred to as the entries, since the	effec-
       tive 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 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 de-
       fault 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 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-de-
       fault ACL entries, and second as	the  subdirectory's  default  ACL  en-
       tries.  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 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 re-
       trieved using the getacl(1) command.  The permissions granted to	a par-
       ticular 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 en-
	       tries 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 af-
	       fects the file's	entry, which would in turn affect the  permis-
	       sions  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 which have	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:

       NACLVENTRIES	   maximum number of entries per ACL,  including  base
			   entries
       NACLBASE		   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 eff gid plus supp groups
       NGROUPS_RGID_SUPP   process's real gid plus supp	groups
       NGROUPS_SGID_SUPP   process's saved gid plus supp 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
       (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
       NFS  NFS	does not support ACLs on remote	files.	Individual manual  en-
	    tries specify the behavior of various system calls,	library	calls,
	    and	commands under these circumstances.  Be	careful	when transfer-
	    ring  a  file with optional	entries	over a network or when manipu-
	    lating 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)  ac-
       cess(2),	 acl(1), 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)

NAME | DESCRIPTION | HEADERS | WARNINGS | DEPENDENCIES | AUTHOR | FILES | SEE ALSO

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=aclv&sektion=5&manpath=HP-UX+11.22>

home | help