Switch to SpeakEasy.net DSL

The Modular Manual Browser

Home Page
Manual: (OSF1-V5.1-alpha)
Apropos / Subsearch:
optional field

acl(4)								       acl(4)


  acl -	Access control list



       The Tru64 UNIX ACLs are based on	the POSIX P1003.6 Draft	13 stan-


  Traditionally, UNIX systems control a	user's access to files and direc-
  tories using a method	of discretionary access	control	(DAC) normally
  referred to as the permission	bits.  By default, Tru64 UNIX systems are run
  using	this method of DAC for files and directories.  This default DAC, the
  permission bits, allows you to set discretionary access permissions for the
  owning user, owning group, and "other".

  Access ACLs provide greater granularity of access permissions	than the
  default Tru64	UNIX DAC.  Access ACLs provide discretionary access permis-
  sions	for the	owning user, owning group, and "other",	and also provide dis-
  cretionary access permissions	for individually specified users and groups.
  An access ACL	containing just	the entries that correspond to the permission
  bits should act identically to no ACL.

  ACLs can be enabled and disabled dynamically and can be enabled separately
  from the other security options.  This allows	you to tailor your system to
  use only the security	options	that you need, instead of having to setup all
  the security options.	 If ACLs are disabled on your system, ACLs can still
  be set on files and directories, but the access ACL will not be used for
  access permission checking and ACL inheritance of any	default	ACLs will not
  take place for newly created files and directories.  See the Security	guide
  for information on enabling and disabling ACLs.

  ACLs are extended file attributes stored in the file or directory's pro-
  perty	list.  Currently ACLs are only supported for files and directories on
  filesystems that support property lists.  These are:	UFS, AdvFS, and	NFS
  when distributed between Tru64 UNIX systems.

  Types	of ACLs	and ACL	Inheritance

  An access ACL	can be associated with a file or directory and controls	the
  access permissions to	the file or directory.

  There	are two	types of default ACLs, the default access ACL and the default
  directory ACL.  The default ACLs are only associated with directories.
  They control what access ACLs	and default ACLs are inherited by new files
  and subdirectories created within a directory	that has default ACL(s).
  When a default ACL is	being inherited	by a new file or directory as an
  access ACL, the permission bits and their associated ACL entries are set to
  the intersection of the permission bits from the default ACL and the mode
  parameter passed to the open(2), creat(2), or	mkdir(2) call, the umask is
  not used.  This usually means	that when you're using a program or utility
  to copy a file, the file gets	the intersection of the	permission bits	from
  the source file and the default ACL, NOT the umask.  The other ACL entries
  in the new access ACL	are set	from the entries in the	default	ACL, neither
  the mode parameter or	the umask affect these entries.

  ACL Commands

  The following	commands display and change the	contents of an ACL:

  setacl    Changes an ACL on a	file or	directory.

  getacl    Displays an	ACL on a file or directory.

  dxsetacl  GUI	for editing and	displaying ACLs

  Contents of an ACL

  A valid ACL must meet	the following requirements:

    +  It must contain the 3 base entries that correspond to the permission
       bits.  These are	the entries for	"owning	user", "owning group", and

    +  Entries can be entered in any order with	setacl.	 They need not
       correspond to the order displayed by getacl.

    +  An ACL must be specified	as either an access, a default access, or a
       default directory ACL.  The default ACLs	are associated with a direc-
       tory only.

    +  Duplicate entries are not allowed within	a given	ACL entry (tag)	type.
       You cannot have two ACL entries with the	same user name or uid, for

  ACL text format:

  The text format of an	ACL consists of	comma (,) or newline (<cr>) separated
  entries.  Each entry has 3 fields, the entry (tag) type, the tag qualifier,
  and the permissions.	The permissions	are represented	similarly to the ls
  -l command.  To restrict permissions,	use a dash (-) in place	of any per-
  mission character.

  There	are 5 different	types of entries:

  user::rwx The	owning user entry, tag qualifier is empty This corresponds to
	    the	owning user permission bits

	    A user entry, tag qualifier	is uid or user name

	    The	owning group entry, tag	qualifier is empty This	corresponds
	    to the owning group	permission bits

	    A group entry, tag qualifier is gid	or group name

	    The	"other"	entry, tag qualifier is	empty This corresponds to the
	    other permission bits

  The owning user entry, the owning group entry, and the other entry are
  called the base entries and they are required.  There	may be zero or more
  user and group entries up to a total of 62 user and group entries in addi-
  tion to the base entries.  This limitation is	based on a property list lim-
  itation in the AdvFS filesystem.  The	limit is configurable on UFS and may
  be raised.  See the Security guide for more information.

  Command Interaction

  Existing commands interact with ACLs as follows:

    +  The chmod command updates the contents of the ACL to match the new
       mode (permission	bits) being set	on the object.

    +  The chown command changes the owning user.  This	command	does not
       change the ACL.	The new	owning user has	the owning user	permissions
       from the	ACL.  The owning user permissions are checked first, so	if
       there is	a separate ACL entry for this user it is ignored.  See the
       Security	guide for a complete description of access checking with

    +  The chgrp command changes the owning group.  This command does not
       change the ACL.	The new	owning group has the owning group permissions
       from the	ACL.  When checking the	ACL, the permissions from all match-
       ing groups are ORed to get the final permissions.  So, if there is a
       separate	ACL entry for this group it is granted in addition to the
       owning group permissions.

    +  Currently ls does NOT give any indication of the	existence of ACLs.

    +  The cp command will not copy ACLs unless	the -p flag is used.

  Programming with ACLs

  There	is an ACL library, libpacl, which contains the functions necessary to
  manipulate ACLs from within a	program.  See Chapter 22 of the	Security
  Guide	and the	individual man pages for descriptions of these functions.

  An ACL has an	internal and an	external representation. The external
  representation consists of text and is used to enter and display ACLs.
  Library routines manipulate ACLs in working storage in an internal
  representation that is only indirectly accessible to the calling routine.
  This internal	representation can be interpreted with the acl.h header	file.

  ACL Initialization

  If any of the	following system calls are used	to create a file or a direc-
  tory,	ACLs are enabled, and there are	default	ACL(s) on the parent direc-
  tory,	ACL inheritance	will take place.

    +  The creat() system call

    +  The open() system call with the O_CREATE	flag

    +  The mkdir() system call

  When a file or directory is created, the default ACL(s) of its parent
  directory are	used in	conjunction with the mode parameter passed to the
  above	system calls to	determine the access ACL and permission	bits of	the
  newly	created	file or	directory.  The	process	umask is not used if default
  ACL inheritance takes	place.	If the parent directory	doesn't	have default
  ACL(s), the process umask and	system call mode parameter are used to deter-
  mine the permissions bits, as	in traditional UNIX permissions.

  For a	description of a process umask,	see the	umask(2) reference page.

  Access Checks

  The stat structure should not	be used	to determine accessability of a	file
  or directory.	 On local filesystems, read-only mounts	and ACLs can both
  modify the access that is allowed.  On remote	filesystems, in	addition to
  read-	only mounts and	ACLs, there may	also be	additional controls that
  alter	the permitted access, such as:

    +  ID mapping

    +  Mandatory access	control

    +  Additional authentication requirements

  The access() call should always be used to do	DAC access checking on a file
  or directory.

  See the Security guide for a description of the access decision process for
  files	and directories	with access ACLs.

  NFS Flatten Mode

  The NFS flatten mode (nfs_flatten_mode) attribute in the "sec" subsystem
  controls the permission bits of a file or directory with an access ACL as
  seen by an NFS V2 client.  The sysconfigdb command should be used to set
  this attribute in the	/etc/sysconfigtab file.

  NFS V2 clients make their own	access decisions based on their	interpreta-
  tion of a file's permission bits.  Based on this decision, they may allow
  access to data cached	on the client from a previous access by	another	user.
  A file that is protected by an access	ACL cannot reflect the correct access
  for all users	in the permission bits for the file.  It may be	that access
  that would be	granted	by the permission bits is actually denied explicitly
  by the access	ACL.  It may also be that access that seems to be denied by
  the permission bits is, in fact, granted explicitly by the access ACL.  The
  nfs-flatten- mode parameter can be used to modify the	permission bits	that
  exist	on the server before presentation to the client.

  NFS V3 clients have, in essence, an "open" protocol request that they	use
  to defer the access decision to the server, and grants access	only when
  they have previously made an "open" request for the same user	and file.

  Setting the nfs-flatten-mode parameter to the	restrictive setting (1)	can
  cause	some users to be denied	access to files	that they should legitimately
  be granted access to.	 Setting the parameter to the permissive setting (2)
  can cause some users to be granted access to files that they should not be
  granted access to, but only for read access to data in the client cache,
  since	any request that is sent to the	server (and all	write requests are
  supposed to be sent to the server) results in	an access decision on the
  server denying the request.  Setting the parameter to	the unmodified set-
  ting (0) leaves the permission bits unmodified, possibly resulting in	both
  inadvertent denial and granting of access, while accurately displaying the
  permission bits on the client	as they	would be displayed on the server.

  The allowable	values are:

  0 - unmodified
       The actual file permission bits are sent.

  1 - restrictive
       The owning group	and other fields of the	file permission	bits are
       modified	such that only access that would be granted to everyone	in
       the ACL is granted by the permission bits.

  2 - permissive
       The owning group	and other fields of the	file permission	bits are
       modified	such that access that is granted to anyone in the ACL is
       granted by the permission bits.

  The default value is 0.



  Commands: setacl(1), chgrp(1), chmod(1), chown(1), getacl(1)



  Files: proplist(4)