GNU.WIKI: The GNU/Linux Knowledge Base

  [HOME] [PHP Manual] [HowTo] [ABS] [MAN1] [MAN2] [MAN3] [MAN4] [MAN5] [MAN6] [MAN7] [MAN8] [MAN9]

  [0-9] [Aa] [Bb] [Cc] [Dd] [Ee] [Ff] [Gg] [Hh] [Ii] [Jj] [Kk] [Ll] [Mm] [Nn] [Oo] [Pp] [Qq] [Rr] [Ss] [Tt] [Uu] [Vv] [Ww] [Xx] [Yy] [Zz]


       nfs4_acl - NFSv4 Access Control Lists


       An ACL is a list of permissions associated with a file or directory and
       consists of one or more Access  Control  Entries  (ACEs).   NFSv4  ACLs
       provide   finer   granularity  than  typical  POSIX  read/write/execute
       permissions and are similar to CIFS ACLs.

       A sample NFSv4 file ACL might look like  the  following  (see  the  ACL
       FORMAT section for detailed information):


       Some observations:

       -  In  the example output above, the user `' has the
          equivalent of "read" and "execute" permissions,  `'
          has  "read"  and  "write",  and  both  `GROUP@' and `EVERYONE@' have

       -  NFSv4 ACLs are "default-deny"; that  is,  if  a  permission  is  not
          explicitly  granted by an Allow ACE, it is denied.  Because of this,
          the two Deny ACEs above are superfluous and could be excluded by the
          server.   See  the  A  WARNING  ABOUT  DENY  ACES  section  for more

       -  NFSv4 servers may return an ACL slightly different than one you set.
          For example, a server that always allows reading the attributes of a
          file may silently turn on  the  read-attributes  permission,  and  a
          server  that  does  not  support separate write-data and append-data
          permissions, e.g., may choose to turn off both if you set only  one.
          In  extreme cases the server may also reorder or combine ACEs.  As a
          general rule, however, servers will attempt to ensure that the  ACLs
          they return are no more permissive than the ones you set.


       An  NFSv4  ACL  is  written  as  an  acl_spec,  which  is  a  comma- or
       whitespace-delimited string consisting of one  or  more  ace_specs.   A
       single NFSv4 ACE is written as an ace_spec, which is a colon-delimited,
       4-field string in the following format:


       There are four types of ACEs, each represented by a  single  character.
       An ACE must have exactly one type.

       A      Allow   -   allow   principal   to   perform  actions  requiring

       D      Deny -  prevent  principal  from  performing  actions  requiring

       U      Audit  -  log  any  attempted access by principal which requires
              permissions.  Requires one or both of the successful-access  and
              failed-access  flags.   System-dependent;  not  supported by all

       L      Alarm - generate a system  alarm  at  any  attempted  access  by
              principal  which  requires permissions.  Requires one or both of
              the  successful-access   and   failed-access   flags.    System-
              dependent; not supported by all servers.

       There   are   three   kinds  of  ACE  flags:  group,  inheritance,  and
       administrative.  An Allow or Deny ACE may contain zero or  more  flags,
       while  an  Audit  or  Alarm  ACE  must  contain  at  least  one  of the
       successful-access and failed-access flags.

       Note that ACEs are inherited from the parent  directory's  ACL  at  the
       time a file or subdirectory is created.  Accordingly, inheritance flags
       can be used only in ACEs  in  a  directory's  ACL  (and  are  therefore
       stripped  from  inherited  ACEs  in  a new file's ACL).  Please see the
       INHERITANCE FLAGS COMMENTARY section for more information.

       GROUP FLAG - can be used in any ACE

       g      group - indicates that principal represents a group instead of a

       INHERITANCE FLAGS - can be used in any directory ACE

       d      directory-inherit  -  newly-created  subdirectories will inherit
              the ACE.

       f      file-inherit - newly-created files will inherit the  ACE,  minus
              its   inheritance   flags.   Newly-created  subdirectories  will
              inherit the ACE; if directory-inherit is not also  specified  in
              the parent ACE, inherit-only will be added to the inherited ACE.

       n      no-propagate-inherit - newly-created subdirectories will inherit
              the ACE, minus its inheritance flags.

       i      inherit-only - the ACE is not considered in permissions  checks,
              but  it is heritable; however, the inherit-only flag is stripped
              from inherited ACEs.

       ADMINISTRATIVE FLAGS - can be used in Audit and Alarm ACEs

       S      successful-access - trigger an  alarm/audit  when  principal  is
              allowed to perform an action covered by permissions.

       F      failed-access   -  trigger  an  alarm/audit  when  principal  is
              prevented from performing an action covered by permissions.

       A principal is either a named user  (e.g.,  `')  or
       group  (provided  the  group flag is also set), or one of three special
       principals:   `OWNER@',   `GROUP@',   and   `EVERYONE@',   which   are,
       respectively, analogous to the POSIX user/group/other distinctions used
       in, e.g., chmod(1).

       There are a variety of different ACE permissions (13 for files, 14  for
       directories),  each  represented  by a single character.  An ACE should
       have one or more of the following permissions specified:

       r      read-data (files) / list-directory (directories)

       w      write-data (files) / create-file (directories)

       a      append-data (files) / create-subdirectory (directories)

       x      execute (files) / change-directory (directories)

       d      delete - delete the file/directory.  Some servers will  allow  a
              delete  to  occur  if  either  this  permission  is  set  in the
              file/directory or if the delete-child permission is set  in  its
              parent direcory.

       D      delete-child  -  remove  a  file or subdirectory from within the
              given directory (directories only)

       t      read-attributes - read the attributes of the file/directory.

       T      write-attributes - write the attributes of the file/directory.

       n      read-named-attributes  -  read  the  named  attributes  of   the

       N      write-named-attributes  -  write  the  named  attributes  of the

       c      read-ACL - read the file/directory NFSv4 ACL.

       C      write-ACL - write the file/directory NFSv4 ACL.

       o      write-owner - change ownership of the file/directory.

       y      synchronize - allow clients to  use  synchronous  I/O  with  the


       Inheritance  flags can be divided into two categories: "primary" (file-
       inherit and directory-inherit); and  "secondary"  (no-propagate-inherit
       and  inherit-only),  which  are significant only insofar as they affect
       the two "primary" flags.

       The no-propagate-inherit  and  inherit-only  flags  can  be  tricky  to
       remember:  the former determines whether or not a new child directory's
       inherited ACE is itself heritable by  a  grandchild  subdirectory;  the
       latter  determines  whether  or  not a heritable ACE affects the parent
       directory itself (in addition to being heritable).  They  can  be  used

       When  a  subdirectory  inherits an ACE from its parent directory's ACL,
       this can happen in one of two different ways, depending on  the  server

       -  In the simple case, that exact same ACE is set in the subdirectory's

       -  In the other case, two different ACEs will instead  be  set  in  the
          subdirectory's  ACL: one with all inheritance flags removed, and one
          with the inherit-only flag added.  The  former  is  the  "effective"
          inherited  ACE  (used in the subdirectory's own permissions checks);
          the latter is the "heritable" inherited ACE (when  the  subdirectory
          has  directories created within it, they inherit it).  This approach
          makes it easier to modify access rights to the  subdirectory  itself
          without modifying its heritable ACEs.


       Deny  ACEs  should  be  avoided whenever possible.  Although they are a
       valid part of NFSv4 ACLs, Deny ACEs can be confusing  and  complicated.
       This  stems  primarily  from  the fact that, unlike POSIX ACLs and CIFS
       ACLs, the ordering of ACEs within  NFSv4  ACLs  affects  how  they  are

       First, it is important to note that (despite some unfortunate ambiguity
       in RFC3530) NFSv4 ACLs are "default-deny" in practice.  That is,  if  a
       permission is not explicitly granted, it is denied.

       In  general,  when  a principal is attempting to perform an action over
       NFSv4 which requires one  or  more  permissions,  an  access  check  is
       performed.   The  NFSv4 ACL (assuming one is present) is evaluated ACE-
       by-ACE until every one of those  permissions  has  been  addressed,  or
       until the end of the ACL is reached.  If every requisite permission was
       granted by Allow ACEs and was not forbidden  by  Deny  ACEs  (see  next
       paragraph), the action is allowed to proceed.  Otherwise, the action is

       Note that each requisite permission is only addressed once -- that  is,
       after a permission has been explicitly Allowed or Denied once during an
       access check,  any  subsequent  ACEs  in  the  ACL  which  affect  that
       permission are no longer considered.  This often introduces problematic
       ordering issues when Deny ACEs are present.

       Additionally, in some cases Group-Deny ACEs can be  difficult  (if  not
       impossible)  to  enforce,  since a server might not know about all of a
       given principal's memberships in remote groups, e.g.

       Because NFSv4 ACLs are "default-deny", the use of Deny  ACEs  can  (and
       should) be avoided entirely in most cases.


       Tools  for  viewing  and  manipulating  NFSv4  ACLs,  nfs4_getfacl  and
       nfs4_setfacl,  were  written  by  people  at  CITI,  the   Center   for
       Information  Technology  Integration (  This
       manpage was written by David Richter and J. Bruce Fields.


       Please  send  bug  reports,   feature   requests,   and   comments   to


       nfs4_getfacl(1),   nfs4_setacl(1),  RFC3530  (NFSv4.0),  NFSv4.1  Minor
       Version Draft.

  All copyrights belong to their respective owners. Other content (c) 2014-2017, GNU.WIKI. Please report site errors to
Page load time: 0.111 seconds. Last modified: November 09 2017 18:38:06.