acl man page on OSF1

Man page or keyword search:  
man Server   12896 pages
apropos Keyword Search (all sections)
Output format
OSF1 logo
[printable version]

acl(4)									acl(4)

       acl - Access control list


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

       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 per‐
       missions 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 per‐
       missions for the owning user, owning group, and “other”, and also  pro‐
       vide  discretionary 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 sepa‐
       rately from the other security options.	This allows you to tailor your
       system  to use only the security options that you need, instead of hav‐
       ing 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
       property list.  Currently ACLs are only supported for files and	direc‐
       tories  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 inher‐
       ited 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 asso‐
       ciated  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:
       Changes	an  ACL	 on a file or directory.  Displays an ACL on a file or
       directory.  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 “other”.	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  directory  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 example.

   ACL Text Format
       The text format of an ACL consists of comma (,) or newline (<cr>) sepa‐
       rated  entries.	Each entry has 3 fields, the entry (tag) type, the tag
       qualifier, and the permissions.	The permissions are represented	 simi‐
       larly to the ls -l command.  To restrict permissions, use a dash (-) in
       place of any permission character.

       There are 5 different types of entries:	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  addition  to the base entries.  This limitation is based on a prop‐
       erty list limitation in the AdvFS filesystem.   The  limit  is  config‐
       urable  on  UFS	and  may  be  raised.  See the Security guide for more

   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 own‐
       ing 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 ACLs.  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 matching 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	 indi‐
       cation  of  the	existence  of ACLs.  The cp command will not copy ACLs
       unless the -p option is used.

   Programming with ACLs
       There is an ACL library, libpacl, which contains the  functions	neces‐
       sary  to manipulate ACLs from within a program.	See 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 rep‐
       resentation  that is only indirectly accessible to the calling routine.
       This internal representation can be interpreted with the <acl.h> header

   ACL Initialization
       If  any	of  the	 following system calls are used to create a file or a
       directory, ACLs are enabled, and there are default ACL(s) on the parent
       directory,  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 determine the permissions bits, as in traditional UNIX per‐

       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”  subsys‐
       tem  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 interpre‐
       tation 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

       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  per‐
       missive	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 setting  (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:  The actual file permission bits are sent.
       The owning group and other fields of the file permission bits are modi‐
       fied such that only access that would be granted to everyone in the ACL
       is granted by the permission bits.  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)

       Functions:   acl_add_perm(3),   acl_clear_perm(3),   acl_copy_entry(3),
       acl_copy_ext(3),		 acl_copy_int(3),	  acl_create_entry(3),
       acl_delete_def_fd(3),   acl_delete_def_file(3),	  acl_delete_entry(3),
       acl_delete_perm(3),    acl_dup(3),   acl_first_entry(3),	  acl_free(3),
       acl_free_qualifier(3),	    acl_free_text(3),	     acl_from_text(3),
       acl_get_entry(3),  acl_get_fd(3),  acl_get_file(3), acl_get_permset(3),
       acl_get_qualifier(3), acl_get_tag_type(3), acl_init(3),	acl_set_fd(3),
       acl_set_file(3),	       acl_set_permset(3),	 acl_set_qualifier(3),
       acl_set_tag_type(3), acl_size(3), acl_to_text(3), acl_valid(3)

       Files: proplist(4)


                             _         _         _ 
                            | |       | |       | |     
                            | |       | |       | |     
                         __ | | __ __ | | __ __ | | __  
                         \ \| |/ / \ \| |/ / \ \| |/ /  
                          \ \ / /   \ \ / /   \ \ / /   
                           \   /     \   /     \   /    
                            \_/       \_/       \_/ 
More information is available in HTML format for server OSF1

List of man pages available for OSF1

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]
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