Пакет: acl

SETFACL(1)		     Access Control Lists		    SETFACL(1)



NAME
       setfacl - set file access control lists

SYNOPSIS
       setfacl [-bkndRLPvh] [{-m|-x} acl_spec] [{-M|-X} acl_file] file ...

       setfacl --restore={file|-}


DESCRIPTION
       This utility sets Access Control Lists (ACLs) of files and directories.
       On the command line, a sequence of commands is followed by  a  sequence
       of  files  (which  in  turn can be followed by another sequence of com‐
       mands, ...).

       The -m and -x options expect an ACL on the command line.	 Multiple  ACL
       entries	are separated by comma characters (`,'). The -M and -X options
       read an ACL from a file or from standard input. The ACL entry format is
       described in Section ACL ENTRIES.

       The  --set and --set-file options set the ACL of a file or a directory.
       The previous ACL is replaced.  ACL entries for this operation must  in‐
       clude permissions.

       The  -m	(--modify)  and -M (--modify-file) options modify the ACL of a
       file or directory.  ACL entries for this operation must include permis‐
       sions.

       The -x (--remove) and -X (--remove-file) options remove ACL entries. It
       is not an error to remove an entry which does not exist.	 Only ACL  en‐
       tries  without  the  perms  field  are  accepted	 as parameters, unless
       POSIXLY_CORRECT is defined.

       When reading from files using the -M and -X  options,  setfacl  accepts
       the  output getfacl produces.  There is at most one ACL entry per line.
       After a Pound sign (`#'), everything up to  the	end  of	 the  line  is
       treated as a comment.

       If  setfacl  is used on a file system which does not support ACLs, set‐
       facl operates on the file mode permission bits. If the ACL does not fit
       completely  in the permission bits, setfacl modifies the file mode per‐
       mission bits to reflect the ACL as closely as possible, writes an error
       message to standard error, and returns with an exit status greater than
       0.


   PERMISSIONS
       The file owner and processes capable  of	 CAP_FOWNER  are  granted  the
       right  to  modify  ACLs of a file. This is analogous to the permissions
       required for accessing the file mode. (On current Linux	systems,  root
       is the only user with the CAP_FOWNER capability.)


OPTIONS
       -b, --remove-all
	   Remove all extended ACL entries. The base ACL entries of the owner,
	   group and others are retained.

       -k, --remove-default
	   Remove the Default ACL. If no Default ACL exists, no	 warnings  are
	   issued.

       -n, --no-mask
	   Do  not recalculate the effective rights mask. The default behavior
	   of setfacl is to recalculate the ACL mask entry, unless a mask  en‐
	   try	was  explicitly	 given.	 The mask entry is set to the union of
	   all permissions of the owning group, and all named user  and	 group
	   entries.  (These  are  exactly the entries affected by the mask en‐
	   try).

       --mask
	   Do recalculate the effective rights mask, even if an ACL mask entry
	   was explicitly given. (See the -n option.)

       -d, --default
	   All operations apply to the Default ACL. Regular ACL entries in the
	   input set are promoted to Default ACL entries. Default ACL  entries
	   in  the  input set are discarded. (A warning is issued if that hap‐
	   pens).

       --restore={file|-}
	   Restore a permission backup created by `getfacl -R' or similar. All
	   permissions of a complete directory subtree are restored using this
	   mechanism. If the input contains owner comments or group  comments,
	   setfacl  attempts to restore the owner and owning group. If the in‐
	   put contains flags comments (which define the setuid,  setgid,  and
	   sticky bits), setfacl sets those three bits accordingly; otherwise,
	   it clears them. This option cannot be mixed with other options  ex‐
	   cept	 `--test'.  If the file specified is '-', then it will be read
	   from standard input.

       --test
	   Test mode. Instead of changing the ACLs of any files, the resulting
	   ACLs are listed.

       -R, --recursive
	   Apply operations to all files and directories recursively. This op‐
	   tion cannot be mixed with `--restore'.

       -L, --logical
	   Logical walk, follow symbolic links to directories. The default be‐
	   havior  is  to  follow  symbolic  link arguments, and skip symbolic
	   links encountered in subdirectories.	 Only effective in combination
	   with -R.  This option cannot be mixed with `--restore'.

       -P, --physical
	   Physical  walk,  do not follow symbolic links to directories.  This
	   also skips symbolic link arguments.	Only effective in  combination
	   with -R.  This option cannot be mixed with `--restore'.

       -v, --version
	   Print the version of setfacl and exit.

       -h, --help
	   Print help explaining the command line options.

       --  End	of  command  line options. All remaining parameters are inter‐
	   preted as file names, even if they start with a dash.

       -   If the file name parameter is a single dash, setfacl reads  a  list
	   of files from standard input.


   ACL ENTRIES
       The  setfacl utility recognizes the following ACL entry formats (blanks
       inserted for clarity):


       [d[efault]:] [u[ser]:]uid [:perms]
	      Permissions of a named user. Permissions of the  file  owner  if
	      uid is empty.

       [d[efault]:] g[roup]:gid [:perms]
	      Permissions of a named group. Permissions of the owning group if
	      gid is empty.

       [d[efault]:] m[ask][:] [:perms]
	      Effective rights mask

       [d[efault]:] o[ther][:] [:perms]
	      Permissions of others.

       Whitespace between delimiter characters and non-delimiter characters is
       ignored.

       Proper ACL entries including permissions are used in modify and set op‐
       erations. (options -m, -M, --set and --set-file).  Entries without  the
       perms field are used for deletion of entries (options -x and -X).

       For  uid	 and gid you can specify either a name or a number.  Character
       literals may be specified with a backslash followed by the 3-digit  oc‐
       tal  digits  corresponding  to  the ASCII code for the character (e.g.,
       \101 for 'A').  If the name contains a literal backslash followed by  3
       digits, the backslash must be escaped (i.e., \\).

       The  perms  field is a combination of characters that indicate the read
       (r), write (w), execute (x) permissions.	 Dash characters in the	 perms
       field  (-) are ignored.	The character X stands for the execute permis‐
       sion if the file is a directory or already has execute  permission  for
       some  user.   Alternatively, the perms field can define the permissions
       numerically, as a bit-wise combination of read (4), write (2), and exe‐
       cute  (1).   Zero  perms	 fields	 or  perms fields that only consist of
       dashes indicate no permissions.

   AUTOMATICALLY CREATED ENTRIES
       Initially, files and directories contain only the three	base  ACL  en‐
       tries  for  the owner, the group, and others. There are some rules that
       need to be satisfied in order for an ACL to be valid:

       *   The three base entries cannot be removed. There must be exactly one
	   entry of each of these base entry types.

       *   Whenever an ACL contains named user entries or named group objects,
	   it must also contain an effective rights mask.

       *   Whenever an ACL contains any Default ACL entries, the three Default
	   ACL base entries (default owner, default group, and default others)
	   must also exist.

       *   Whenever a Default ACL contains named user entries or  named	 group
	   objects, it must also contain a default effective rights mask.

       To  help	 the user ensure these rules, setfacl creates entries from ex‐
       isting entries under the following conditions:

       *   If an ACL contains named user or named group entries, and  no  mask
	   entry  exists,  a mask entry containing the same permissions as the
	   group entry is created. Unless the -n option is given, the  permis‐
	   sions  of  the mask entry are further adjusted to include the union
	   of all permissions affected by the mask entry. (See the  -n	option
	   description).

       *   If  a Default ACL entry is created, and the Default ACL contains no
	   owner, owning group, or others entry, a copy of the ACL owner, own‐
	   ing group, or others entry is added to the Default ACL.

       *   If  a  Default  ACL	contains named user entries or named group en‐
	   tries, and no mask entry exists, a mask entry containing  the  same
	   permissions	as the default Default ACL's group entry is added. Un‐
	   less the -n option is given, the permissions of the mask entry  are
	   further  adjusted  to include the union of all permissions affected
	   by the mask entry. (See the -n option description).

EXAMPLES
       Granting an additional user read access
	      setfacl -m u:lisa:r file

       Revoking write access from all groups and all named  users  (using  the
       effective rights mask)
	      setfacl -m m::rx file

       Removing a named group entry from a file's ACL
	      setfacl -x g:staff file

       Copying the ACL of one file to another
	      getfacl file1 | setfacl --set-file=- file2

       Copying the access ACL into the Default ACL
	      getfacl --access dir | setfacl -d -M- dir

CONFORMANCE TO POSIX 1003.1e DRAFT STANDARD 17
       If the environment variable POSIXLY_CORRECT is defined, the default be‐
       havior of setfacl changes as follows: All non-standard options are dis‐
       abled.	The  ``default:''  prefix  is disabled.	 The -x and -X options
       also accept permission fields (and ignore them).

AUTHOR
       Andreas Gruenbacher, <andreas.gruenbacher@gmail.com>.

       Please send your bug reports, suggested features and  comments  to  the
       above address.

SEE ALSO
       getfacl(1), chmod(1), umask(1), acl(5)



May 2000		      ACL File Utilities		    SETFACL(1)

ACL(5)			    BSD File Formats Manual			ACL(5)

NAME
     acl — Access Control Lists

DESCRIPTION
     This manual page describes POSIX Access Control Lists, which are used to
     define more fine-grained discretionary access rights for files and direc‐
     tories.

ACL TYPES
     Every object can be thought of as having associated with it an ACL that
     governs the discretionary access to that object; this ACL is referred to
     as an access ACL. In addition, a directory may have an associated ACL
     that governs the initial access ACL for objects created within that di‐
     rectory; this ACL is referred to as a default ACL.

ACL ENTRIES
     An ACL consists of a set of ACL entries. An ACL entry specifies the ac‐
     cess permissions on the associated object for an individual user or a
     group of users as a combination of read, write and search/execute permis‐
     sions.

     An ACL entry contains an entry tag type, an optional entry tag qualifier,
     and a set of permissions.	We use the term qualifier to denote the entry
     tag qualifier of an ACL entry.

     The qualifier denotes the identifier of a user or a group, for entries
     with tag types of ACL_USER or ACL_GROUP, respectively. Entries with tag
     types other than ACL_USER or ACL_GROUP have no defined qualifiers.

     The following entry tag types are defined:

	   ACL_USER_OBJ	   The ACL_USER_OBJ entry denotes access rights for
			   the file owner.

	   ACL_USER	   ACL_USER entries denote access rights for users
			   identified by the entry's qualifier.

	   ACL_GROUP_OBJ   The ACL_GROUP_OBJ entry denotes access rights for
			   the file group.

	   ACL_GROUP	   ACL_GROUP entries denote access rights for groups
			   identified by the entry's qualifier.

	   ACL_MASK	   The ACL_MASK entry denotes the maximum access
			   rights that can be granted by entries of type
			   ACL_USER, ACL_GROUP_OBJ, or ACL_GROUP.

	   ACL_OTHER	   The ACL_OTHER entry denotes access rights for pro‐
			   cesses that do not match any other entry in the
			   ACL.

     When an access check is performed, the ACL_USER_OBJ and ACL_USER entries
     are tested against the effective user ID. The effective group ID, as well
     as all supplementary group IDs are tested against the ACL_GROUP_OBJ and
     ACL_GROUP entries.

VALID ACLs
     A valid ACL contains exactly one entry with each of the ACL_USER_OBJ,
     ACL_GROUP_OBJ, and ACL_OTHER tag types. Entries with ACL_USER and
     ACL_GROUP tag types may appear zero or more times in an ACL. An ACL that
     contains entries of ACL_USER or ACL_GROUP tag types must contain exactly
     one entry of the ACL_MASK tag type. If an ACL contains no entries of
     ACL_USER or ACL_GROUP tag types, the ACL_MASK entry is optional.

     All user ID qualifiers must be unique among all entries of ACL_USER tag
     type, and all group IDs must be unique among all entries of ACL_GROUP tag
     type.

       The acl_get_file() function returns an ACL with zero ACL entries as the
     default ACL of a directory, if the directory is not associated with a de‐
     fault ACL. The acl_set_file() function also accepts an ACL with zero ACL
     entries as a valid default ACL for directories, denoting that the direc‐
     tory shall not be associated with a default ACL. This is equivalent to
     using the acl_delete_def_file() function.

CORRESPONDENCE BETWEEN ACL ENTRIES AND FILE PERMISSION BITS
     The permissions defined by ACLs are a superset of the permissions speci‐
     fied by the file permission bits.

     There is a correspondence between the file owner, group, and other per‐
     missions and specific ACL entries: the owner permissions correspond to
     the permissions of the ACL_USER_OBJ entry. If the ACL has an ACL_MASK en‐
     try, the group permissions correspond to the permissions of the ACL_MASK
     entry.  Otherwise, if the ACL has no ACL_MASK entry, the group permis‐
     sions correspond to the permissions of the ACL_GROUP_OBJ entry.  The
     other permissions correspond to the permissions of the ACL_OTHER entry.

     The file owner, group, and other permissions always match the permissions
     of the corresponding ACL entry. Modification of the file permission bits
     results in the modification of the associated ACL entries, and modifica‐
     tion of these ACL entries results in the modification of the file permis‐
     sion bits.

OBJECT CREATION AND DEFAULT ACLs
     The access ACL of a file object is initialized when the object is created
     with any of the creat(), mkdir(), mknod(), mkfifo(), or open() functions.
     If a default ACL is associated with a directory, the mode parameter to
     the functions creating file objects and the default ACL of the directory
     are used to determine the ACL of the new object:

     1.	  The new object inherits the default ACL of the containing directory
	  as its access ACL.

     2.	  The access ACL entries corresponding to the file permission bits are
	  modified so that they contain no permissions that are not contained
	  in the permissions specified by the mode parameter.

     If no default ACL is associated with a directory, the mode parameter to
     the functions creating file objects and the file creation mask (see
     umask(2)) are used to determine the ACL of the new object:

     1.	  The new object is assigned an access ACL containing entries of tag
	  types ACL_USER_OBJ, ACL_GROUP_OBJ, and ACL_OTHER. The permissions of
	  these entries are set to the permissions specified by the file cre‐
	  ation mask.

     2.	  The access ACL entries corresponding to the file permission bits are
	  modified so that they contain no permissions that are not contained
	  in the permissions specified by the mode parameter.

ACCESS CHECK ALGORITHM
     A process may request read, write, or execute/search access to a file ob‐
     ject protected by an ACL. The access check algorithm determines whether
     access to the object will be granted.

     1.	  If the effective user ID of the process matches the user ID of the
	  file object owner, then

		if  the ACL_USER_OBJ entry contains the requested permissions,
		access is granted,

		else access is denied.

     2.	  else if the effective user ID of the process matches the qualifier
	  of any entry of type ACL_USER, then

		if  the matching ACL_USER entry and the ACL_MASK entry contain
		the requested permissions, access is granted,

		else access is denied.

     3.	  else if the effective group ID or any of the supplementary group IDs
	  of the process match the file group or the qualifier of any entry of
	  type ACL_GROUP, then

		if the ACL contains an ACL_MASK entry, then

		      if  the  ACL_MASK	 entry	and  any   of	the   matching
		      ACL_GROUP_OBJ or ACL_GROUP entries contain the requested
		      permissions, access is granted,

		      else access is denied.

		else (note that there can be no ACL_GROUP entries  without  an
		ACL_MASK entry)

		      if  the  ACL_GROUP_OBJ entry contains the requested per‐
		      missions, access is granted,

		      else access is denied.

     4.	  else if the ACL_OTHER entry contains the requested permissions, ac‐
	  cess is granted.

     5.	  else access is denied.

ACL TEXT FORMS
     A long and a short text form for representing ACLs is defined. In both
     forms, ACL entries are represented as three colon separated fields: an
     ACL entry tag type, an ACL entry qualifier, and the discretionary access
     permissions. The first field contains one of the following entry tag type
     keywords:

	   user	   A user ACL entry specifies the access granted to either the
		   file owner (entry tag type ACL_USER_OBJ) or a specified
		   user (entry tag type ACL_USER).

	   group   A group ACL entry specifies the access granted to either
		   the file group (entry tag type ACL_GROUP_OBJ) or a speci‐
		   fied group (entry tag type ACL_GROUP).

	   mask	   A mask ACL entry specifies the maximum access which can be
		   granted by any ACL entry except the user entry for the file
		   owner and the other entry (entry tag type ACL_MASK).

	   other   An other ACL entry specifies the access granted to any
		   process that does not match any user or group ACL entries
		   (entry tag type ACL_OTHER).

     The second field contains the user or group identifier of the user or
     group associated with the ACL entry for entries of entry tag type
     ACL_USER or ACL_GROUP, and is empty for all other entries. A user identi‐
     fier can be a user name or a user ID number in decimal form. A group
     identifier can be a group name or a group ID number in decimal form.

     The third field contains the discretionary access permissions. The read,
     write and search/execute permissions are represented by the r, w, and x
     characters, in this order. Each of these characters is replaced by the -
     character to denote that a permission is absent in the ACL entry.	When
     converting from the text form to the internal representation, permissions
     that are absent need not be specified.

     White space is permitted at the beginning and end of each ACL entry, and
     immediately before and after a field separator (the colon character).

   LONG TEXT FORM
     The long text form contains one ACL entry per line. In addition, a number
     sign (#) may start a comment that extends until the end of the line. If
     an ACL_USER, ACL_GROUP_OBJ or ACL_GROUP ACL entry contains permissions
     that are not also contained in the ACL_MASK entry, the entry is followed
     by a number sign, the string “effective:”, and the effective access per‐
     missions defined by that entry. This is an example of the long text form:

	   user::rw-
	   user:lisa:rw-	 #effective:r--
	   group::r--
	   group:toolies:rw-	 #effective:r--
	   mask::r--
	   other::r--

   SHORT TEXT FORM
     The short text form is a sequence of ACL entries separated by commas, and
     is used for input. Comments are not supported. Entry tag type keywords
     may either appear in their full unabbreviated form, or in their single
     letter abbreviated form. The abbreviation for user is u, the abbreviation
     for group is g, the abbreviation for mask is m, and the abbreviation for
     other is o.  The permissions may contain at most one each of the follow‐
     ing characters in any order: r, w, x.  These are examples of the short
     text form:

	   u::rw-,u:lisa:rw-,g::r--,g:toolies:rw-,m::r--,o::r--
	   g:toolies:rw,u:lisa:rw,u::wr,g::r,o::r,m::r

RATIONALE
     IEEE 1003.1e draft 17 defines Access Control Lists that include entries
     of tag type ACL_MASK, and defines a mapping between file permission bits
     that is not constant. The standard working group defined this relatively
     complex interface in order to ensure that applications that are compliant
     with IEEE 1003.1 (“POSIX.1”) will still function as expected on systems
     with ACLs. The IEEE 1003.1e draft 17 contains the rationale for choosing
     this interface in section B.23.

CHANGES TO THE FILE UTILITIES
     On a system that supports ACLs, the file utilities ls(1), cp(1), and
     mv(1) change their behavior in the following way:

     •	 For files that have a default ACL or an access ACL that contains more
	 than the three required ACL entries, the ls(1) utility in the long
	 form produced by ls -l displays a plus sign (+) after the permission
	 string.

     •	 If the -p flag is specified, the cp(1) utility also preserves ACLs.
	 If this is not possible, a warning is produced.

     •	   The mv(1) utility always preserves ACLs. If this is not possible, a
	 warning is produced.

     The effect of the chmod(1) utility, and of the chmod(2) system call, on
     the access ACL is described in CORRESPONDENCE BETWEEN ACL ENTRIES AND
     FILE PERMISSION BITS.

STANDARDS
     The IEEE 1003.1e draft 17 (“POSIX.1e”) document describes several secu‐
     rity extensions to the IEEE 1003.1 standard. While the work on 1003.1e
     has been abandoned, many UNIX style systems implement parts of POSIX.1e
     draft 17, or of earlier drafts.

     Linux Access Control Lists implement the full set of functions and utili‐
     ties defined for Access Control Lists in POSIX.1e, and several exten‐
     sions.  The implementation is fully compliant with POSIX.1e draft 17; ex‐
     tensions are marked as such.  The Access Control List manipulation func‐
     tions are defined in the ACL library (libacl, -lacl). The POSIX compliant
     interfaces are declared in the <sys/acl.h> header.	 Linux-specific exten‐
     sions to these functions are declared in the <acl/libacl.h> header.

NOTES
   DENIED PERMISSIONS AND LINUX USER NAMESPACES
     While ACLs can be used to deny processes permissions based on the groups
     they are in, this is considered bad practice.  Privileged helpers such as
     newuidmap(1) can give unprivileged processes access to the setgroups(2)
     system call, which allows them to drop supplementary group membership and
     render restrictions based on that membership ineffective.	For further
     details, see user_namespaces(7).

SEE ALSO
     chmod(1), creat(2), getfacl(1), ls(1), mkdir(2), mkfifo(2), mknod(2),
     mount(8), open(2), setfacl(1), stat(2), umask(1)

   POSIX 1003.1e DRAFT 17
     https://wt.tuxomania.net/publications/posix.1e/download.html

   POSIX 1003.1e FUNCTIONS BY CATEGORY
     ACL storage management
	  acl_dup(3), acl_free(3), acl_init(3)

     ACL entry manipulation
	  acl_copy_entry(3), acl_create_entry(3), acl_delete_entry(3),
	  acl_get_entry(3), acl_valid(3)

	  acl_add_perm(3), acl_calc_mask(3), acl_clear_perms(3),
	  acl_delete_perm(3), acl_get_permset(3), acl_set_permset(3)

	  acl_get_qualifier(3), acl_get_tag_type(3), acl_set_qualifier(3),
	  acl_set_tag_type(3)

     ACL manipulation on an object
	  acl_delete_def_file(3), acl_get_fd(3), acl_get_file(3),
	  acl_set_fd(3), acl_set_file(3)

     ACL format translation
	  acl_copy_entry(3), acl_copy_ext(3), acl_from_text(3),
	  acl_to_text(3), acl_size(3)

   POSIX 1003.1e FUNCTIONS BY AVAILABILITY
     The first group of functions is supported on most systems with POSIX-like
     access control lists, while the second group is supported on fewer sys‐
     tems.  For applications that will be ported the second group is best
     avoided.

     acl_delete_def_file(3), acl_dup(3), acl_free(3), acl_from_text(3),
     acl_get_fd(3), acl_get_file(3), acl_init(3), acl_set_fd(3),
     acl_set_file(3), acl_to_text(3), acl_valid(3)

     acl_add_perm(3), acl_calc_mask(3), acl_clear_perms(3), acl_copy_entry(3),
     acl_copy_ext(3), acl_copy_int(3), acl_create_entry(3),
     acl_delete_entry(3), acl_delete_perm(3), acl_get_entry(3),
     acl_get_permset(3), acl_get_qualifier(3), acl_get_tag_type(3),
     acl_set_permset(3), acl_set_qualifier(3), acl_set_tag_type(3),
     acl_size(3)

   LINUX EXTENSIONS
     These non-portable extensions are available on Linux systems.

     acl_check(3), acl_cmp(3), acl_entries(3), acl_equiv_mode(3),
     acl_error(3), acl_extended_fd(3), acl_extended_file(3),
     acl_extended_file_nofollow(3), acl_from_mode(3), acl_get_perm(3),
     acl_to_any_text(3)

AUTHOR
     Andreas Gruenbacher, <andreas.gruenbacher@gmail.com>

Linux ACL			March 23, 2002			     Linux ACL

GETFACL(1)		     Access Control Lists		    GETFACL(1)



NAME
       getfacl - get file access control lists

SYNOPSIS
       getfacl [-aceEsRLPtpndvh] file ...

       getfacl [-aceEsRLPtpndvh] -


DESCRIPTION
       For  each  file,	 getfacl displays the file name, owner, the group, and
       the Access Control List (ACL). If a directory has a default  ACL,  get‐
       facl also displays the default ACL. Non-directories cannot have default
       ACLs.

       If getfacl is used on a file system that does not support ACLs, getfacl
       displays	 the  access  permissions defined by the traditional file mode
       permission bits.

       The output format of getfacl is as follows:
	       1:  # file: somedir/
	       2:  # owner: lisa
	       3:  # group: staff
	       4:  # flags: -s-
	       5:  user::rwx
	       6:  user:joe:rwx		      #effective:r-x
	       7:  group::rwx		      #effective:r-x
	       8:  group:cool:r-x
	       9:  mask::r-x
	      10:  other::r-x
	      11:  default:user::rwx
	      12:  default:user:joe:rwx	      #effective:r-x
	      13:  default:group::r-x
	      14:  default:mask::r-x
	      15:  default:other::---


       Lines 1--3 indicate the file name, owner, and owning group.

       Line 4 indicates the setuid (s), setgid (s), and sticky (t)  bits:  ei‐
       ther  the letter representing the bit, or else a dash (-). This line is
       included if any of those bits is set and left out otherwise, so it will
       not  be	shown  for most files. (See CONFORMANCE TO POSIX 1003.1e DRAFT
       STANDARD 17 below.)

       Lines 5, 7 and 10 correspond to the user, group and other fields of the
       file mode permission bits. These three are called the base ACL entries.
       Lines 6 and 8 are named user and named group entries. Line 9 is the ef‐
       fective	rights mask. This entry limits the effective rights granted to
       all groups and to named users. (The file owner and  others  permissions
       are  not affected by the effective rights mask; all other entries are.)
       Lines 11--15 display the default ACL associated	with  this  directory.
       Directories  may have a default ACL. Regular files never have a default
       ACL.

       The default behavior for getfacl is to display both the ACL and the de‐
       fault  ACL,  and to include an effective rights comment for lines where
       the rights of the entry differ from the effective rights.

       If output is to a terminal, the effective rights comment is aligned  to
       column  40.  Otherwise,	a single tab character separates the ACL entry
       and the effective rights comment.

       The ACL listings of multiple files are separated by blank  lines.   The
       output of getfacl can also be used as input to setfacl.


   PERMISSIONS
       Process	with search access to a file (i.e., processes with read access
       to the containing directory of a file) are also granted read access  to
       the file's ACLs.	 This is analogous to the permissions required for ac‐
       cessing the file mode.


OPTIONS
       -a, --access
	   Display the file access control list.

       -d, --default
	   Display the default access control list.

       -c, --omit-header
	   Do not display the comment header (the first three  lines  of  each
	   file's output).

       -e, --all-effective
	   Print  all  effective  rights  comments,  even  if identical to the
	   rights defined by the ACL entry.

       -E, --no-effective
	   Do not print effective rights comments.

       -s, --skip-base
	   Skip files that only have the base ACL entries (owner, group,  oth‐
	   ers).

       -R, --recursive
	   List the ACLs of all files and directories recursively.

       -L, --logical
	   Logical walk, follow symbolic links to directories. The default be‐
	   havior is to follow symbolic	 link  arguments,  and	skip  symbolic
	   links encountered in subdirectories.	 Only effective in combination
	   with -R.

       -P, --physical
	   Physical walk, do not follow symbolic links	to  directories.  This
	   also	 skips symbolic link arguments.	 Only effective in combination
	   with -R.

       -t, --tabular
	   Use an alternative tabular output format. The ACL and  the  default
	   ACL	are  displayed	side by side. Permissions that are ineffective
	   due to the ACL mask entry are displayed capitalized. The entry  tag
	   names  for the ACL_USER_OBJ and ACL_GROUP_OBJ entries are also dis‐
	   played in capital letters, which helps in spotting those entries.

       -p, --absolute-names
	   Do not strip leading slash characters (`/'). The  default  behavior
	   is to strip leading slash characters.

       -n, --numeric
	   List numeric user and group IDs

       -v, --version
	   Print the version of getfacl and exit.

       -h, --help
	   Print help explaining the command line options.

       --  End	of  command  line options. All remaining parameters are inter‐
	   preted as file names, even if they start with a dash character.

       -   If the file name parameter is  a  single  dash  character,  getfacl
	   reads a list of files from standard input.


CONFORMANCE TO POSIX 1003.1e DRAFT STANDARD 17
       If the environment variable POSIXLY_CORRECT is defined, the default be‐
       havior of getfacl changes in the following ways: Unless otherwise spec‐
       ified,  only the ACL is printed. The default ACL is only printed if the
       -d option is given. If no command line parameter is given, getfacl  be‐
       haves  as  if it was invoked as ``getfacl -''.  No flags comments indi‐
       cating the setuid, setgid, and sticky bits are generated.

AUTHOR
       Andreas Gruenbacher, <andreas.gruenbacher@gmail.com>.

       Please send your bug reports and comments to the above address.

SEE ALSO
       setfacl(1), acl(5)



May 2000		      ACL File Utilities		    GETFACL(1)

CHACL(1)		     Access Control Lists		      CHACL(1)



NAME
       chacl - change the access control list of a file or directory

SYNOPSIS
       chacl acl pathname...
       chacl -b acl dacl pathname...
       chacl -d dacl pathname...
       chacl -R pathname...
       chacl -D pathname...
       chacl -B pathname...
       chacl -l pathname...
       chacl -r pathname...

DESCRIPTION
       chacl  is  an  IRIX-compatibility  command, and is maintained for those
       users who are familiar with its use from either XFS or IRIX.  Refer  to
       the  SEE	 ALSO  section	below for a description of tools which conform
       more closely to the (withdrawn draft) POSIX 1003.1e standard which  de‐
       scribes Access Control Lists (ACLs).

       chacl changes the ACL(s) for a file or directory.  The ACL(s) specified
       are applied to each file in the pathname arguments.

       Each ACL is a string which is interpreted  using	 the  acl_from_text(3)
       routine.	  These strings are made up of comma separated clauses each of
       which is of the form, tag:name:perm.  Where tag can be:

       "user" (or "u")
	      indicating that the entry is a "user" ACL entry.

       "group" (or "g")
	      indicating that the entry is a "group" ACL entry.

       "other" (or "o")
	      indicating that the entry is an "other" ACL entry.

       "mask" (or "m")
	      indicating that the entry is a "mask" ACL entry.

       name is a string which is the user or group name for the ACL entry.   A
       null  name  in  a user or group ACL entry indicates the file's owner or
       file's group.  perm is the string "rwx" where each of the  entries  may
       be  replaced  by	 a  "-" indicating no access of that type, e.g. "r-x",
       "--x", "---".

OPTIONS
       -b     Indicates that there are two ACLs to change, the	first  is  the
	      file access ACL and the second the directory default ACL.

       -d     Used to set only the default ACL of a directory.

       -R     Removes the file access ACL only.

       -D     Removes directory default ACL only.

       -B     Remove all ACLs.

       -l     Lists  the  access  ACL  and possibly the default ACL associated
	      with the specified files or directories.	This option was	 added
	      during the Linux port of XFS, and is not IRIX compatible.

       -r     Set  the access ACL recursively for each subtree rooted at path‐
	      name(s).	This option was also added during the  Linux  port  of
	      XFS, and is not compatible with IRIX.

EXAMPLES
       A minimum ACL:

	 chacl u::rwx,g::r-x,o::r-- file

       The  file  ACL  is  set	so that the file's owner has "rwx", the file's
       group has read and execute, and others have read	 only  access  to  the
       file.

       An ACL that is not a minimum ACL, that is, one that specifies a user or
       group other than the file's owner or owner's group, must contain a mask
       entry:

	 chacl u::rwx,g::r-x,o::r--,u:bob:r--,m::r-x file1 file2

       To  set the default and access ACLs on newdir to be the same as on old‐
       dir, you could type:

	 chacl -b `chacl -l olddir | \
	     sed -e 's/.*\[//' -e 's#/# #' -e 's/]$//'` newdir

CAUTIONS
       chacl can replace the existing ACL.  To add or delete entries, you must
       first  do  chacl -l to get the existing ACL, and use the output to form
       the arguments to chacl.

       Changing the permission bits of a file will change the file access  ACL
       settings	 (see  chmod(1)).   However,  file  creation  mode  masks (see
       umask(1)) will not affect the access ACL settings of files created  us‐
       ing directory default ACLs.

       ACLs  are  filesystem  extended	attributes and hence are not typically
       archived or restored using the conventional archiving  utilities.   See
       attr(5)	for  more  information	about extended attributes and see xfs‐
       dump(8) for a method of backing them up under XFS.

SEE ALSO
       getfacl(1), setfacl(1), chmod(1), umask(1),  acl_from_text(3),  acl(5),
       xfsdump(8)



September 2001		      ACL File Utilities		      CHACL(1)