*nix Documentation Project
·  Home
 +   man pages
·  Linux HOWTOs
·  FreeBSD Tips
·  *niX Forums

  man pages->IRIX man pages -> acl (4)              
Title
Content
Arch
Section
 

e(3c)

Contents


acl(4)									acl(4)


NAME    [Toc]    [Back]

     acl - Access Control Lists

SYNOPSIS    [Toc]    [Back]

     #include <sys/acl.h>

DESCRIPTION    [Toc]    [Back]

     Access Control Lists (ACLs) are supported on XFS file systems only.

     ACLs provide a mechanism for finer	grained	access control than the
     traditional UNIX discretionary access control mechanism.  An ACL is a
     list of users and/or groups and their access rights, which	is associated
     with a file or directory.	ACLs are optional.  In addition	to the ACL
     used to mediate access, a directory may have a second ACL which defines
     the default initial ACL for files created in that directory.  Files have
     only the single access control ACL.

     At	the interface to the library routines, ACLs are	represented in a
     struct acl	which is defined in <sys/acl.h>.

	      #define ACL_MAX_ENTRIES 25

	      typedef ushort  acl_perm_t;
	      typedef int     acl_type_t;
	      typedef int     acl_tag_t;

	      struct acl_entry {
		   acl_tag_t	   ae_tag;
		   uid_t	   ae_id;
		   acl_perm_t	   ae_perm;
	      };
	      typedef struct acl_entry * acl_entry_t;

	      struct acl {
		   int			   acl_cnt;
		   struct acl_entry	   acl_entry[ACL_MAX_ENTRIES];
	      };


     This is a fixed size structure with a variable number of active struct
     acl_entry entries.	 The maximum number of entries is ACL_MAX_ENTRIES
     which is currently	defined	to be 25.  The number of active	entries	is
     indicated in acl_cnt.

     A struct acl_entry	consists of three fields, ae_tag, which	identifies the
     type of the entry,	and is one of the following values (all	other values
     are invalid):

     ACL_USER_OBJ (0x01)
		    access permissions for the file's owner.





									Page 1






acl(4)									acl(4)



     ACL_USER (0x02)
		    access permissions for a user other	than the owner.

     ACL_GROUP_OBJ (0x04)
		    access permissions for users with the same group as	the
		    file's group

     ACL_GROUP (0x08)
		    access permissions for other groups

     ACL_MASK (0x10)
		    mask entry

     ACL_OTHER_OBJ (0x20)
		    other entry.

		    The	ae_id field of struct acl_entry	specifies the UID or
		    GID	for the	entry.	The ae_perm field specifies the
		    permissions	using the following defined values:

     ACL_READ (0x04)
		    read access	permitted

     ACL_WRITE (0x02)
		    write access permitted

     ACL_EXECUTE (0x01)
		    execute (search for	directories) access permitted

     As	with the basic permissions for a file, these may be or'ed together.

     Two types of ACLs are defined. ACL_TYPE_ACCESS (0)	indicates that the ACL
     is	to be used in making access control decisions for the file or
     directory with which it is	associated.  ACL_TYPE_DEFAULT (1) indicates
     that the ACL is a default ACL.  Default ACLs are associated only with
     directories, and supply the initial ACL for a file	created	in that
     directory.	Note that file-creation	mode masks may effect the ACLs of
     files created as a	result of using	directory default ACLs (see umask(1)).
     ACLs are supplied using the acl_get_fil
 calls.

EXTERNAL REPRESENTATION    [Toc]    [Back]

     ACLs are represented in a standard	format for human readable input	/
     output.  Each ACL entry is	specified as three colon separated fields.
     ACL entries are separated by white	space or new lines. Everything after a
     "#" character is considered a comment and is ignored to the end of	the
     line.  The	first field of an ACL entry is the entry type, which can be
     one of the	following:  "user", "group", "other", "mask", "u", "g",	"o",
     "m".

     The second	field is a user	name, numeric UID, group name, or numeric GID,
     depending on the value of the first field.	 (acl_from_text(3c) supports
     only the strings, not the numeric UID/GID values.)	 If the	second field



									Page 2






acl(4)									acl(4)



     is	empty, it implies that the ACL entry is	for the	owning user or group
     of	the file.  Mask	and other entries must have an empty second field.
     The third field is	the discretionary access permissions for this ACL
     entry.  This may be represented in	two forms.  The	first is the string
     "rwx" where each letter may be replaced by	a "-" indicating no access of
     that type.	 The parsing of	this string by acl_from_text(3c) requires that
     it	be exactly as shown and	not be reordered, e.g. rxw is not valid.

     Some programs allow a second form,	the relative symbolic form (used for
     input).  The relative symbolic form is preceded by	a ``+''	to indicate
     additional	access or a ``^'' to indicate that access is to	be removed,
     similarly to the inputs to	the chmod(1) command.  The relative symbolic
     string is at least	one character.	The symbolic string contains at	most
     one each of the following characters in any order:	"r", "w", and "x".


									PPPPaaaaggggeeee 3333
[ Back ]
 Similar pages
Name OS Title
acl HP-UX introduction to HFS access control lists
acl_db IRIX database of Access Control Lists
aclv HP-UX introduction to JFS access control lists (ACLs)
dcecp_acl HP-UX A dcecp object that manages DCE access control lists
acl FreeBSD virtual file system access control lists
lsacl HP-UX list access control lists (ACLs) of files
setacl HP-UX modify access control lists (ACLs) for files (JFS File Systems only)
getacl HP-UX list access control lists (ACLs) for files (JFS File Systems only)
chacl HP-UX add, modify, delete, copy, or summarize access control lists (ACLs) of files
swacl HP-UX view or modify the Access Control Lists (ACLs) which protect software products
Copyright © 2004-2005 DeniX Solutions SRL
newsletter delivery service