acl(7) 맨 페이지 - 윈디하나의 솔라나라


맨 페이지 이름


Standards, Environments, Macros, Character Sets, and miscellany

       acl - Access Control Lists

       Access control lists (ACLs) are discretionary access control mechanisms
       that grant and deny access to files and directories. Two different  ACL
       models  are supported in the Solaris release:POSIX-draft ACLs and NFSv4

       The older, POSIX-draft model is supported by the UFS file system.  This
       model  is  based  on a withdrawn ACL POSIX specification that was never
       standardized. It was subsequently withdrawn by the POSIX committee.

       The other model is based on the standards of the  NFSv4  working  group
       and  is  an  approved standard from the Internet Engineering Task Force
       (IETF). The ZFS file system uses the NFSv4 model, and  provides  richer
       semantics  and  finer  grained  permission capabilities than the POSIX-
       draft model.

   POSIX-draft ACLs
       POSIX-draft ACLs provide an alternative  security  mechanism  to  basic
       UNIX  file permissions in the Solaris release. Their purpose is to fur‐
       ther restrict access to files and directories or to extend  permissions
       to  a  particular  user. ACLs can be used to change the permissions for
       the standard owner, group and other class bits of a file's  mode.  ACLs
       can  give  additional  users and groups access to the file. A directory
       can also have a special kind of ACL called a default ACL, which defines
       ACL  entries  to  be  inherited by descendents of the directory. POSIX-
       draft ACLs have an ACL entry called mask. The mask defines the  maximum
       permissions  that  can be granted to additional user and group entries.
       Whenever a file is created or  its  mode  is  changed  by  chmod(1)  or
       chmod(2), the mask is recomputed. It is recomputed to be the group per‐
       mission defined in the mode passed to chmod(2).

       The POSIX-draft ACL model uses the standard rwx  model  of  traditional
       UNIX permissions.

       An ACL is represented as follows:


       Each  acl_entry  contains one ACL entry. An ACL entry is represented by
       two or three colon-separated(:) fields.

       user:[uid]:perms     If uid blank, it represents the file owner.

       group:[gid]:perms    If gid is blank, it represents the owning group.

       other:perms          Represents the file other class.

       mask:perms           Defines the MAX permission to hand out.

       For example to give user joe read and write permissions, the ACL  entry
       is specified as:


   NFSv4 ACLs
       NFSv4  ACL  model  is  based loosely on the Windows NT ACL model. NFSv4
       ACLs provide a much richer ACL model than POSIX-draft ACLs.

       The major differences between NFSv4 and POSIX-draft ACLs  are  as  fol‐

           o      NFSv4  ACLs  provide  finer grained permissions than the rwx

           o      NFSv4 ACLs allow for both ALLOW and DENY entries.

           o      NFSv4 ACLs provide a  rich  set  of  inheritance  semantics.
                  POSIX  ACLs  also have inheritance, but with the NFSv4 model
                  you can control the following inheritance features:

               o      Whether inheritance cascades to both files and  directo‐
                      ries or only to files or directories.

               o      In  the  case  of  directories, you can indicate whether
                      inheritance is applied to the directory itself, to  just
                      one  level  of subdirectories, or cascades to all subdi‐
                      rectories of the directory.

           o      NFSv4 ACLs provide a mechanism for hooking into  a  system's
                  audit  trail,  and for generating alarms. Currently, Solaris
                  does not support alarm generation.

           o      NFSv4 ACLs enable administrators to  specify  the  order  in
                  which  ACL  entries  are  checked. With POSIX-draft ACLs the
                  file system reorders ACL entries into a well defined, strict
                  access, checking order.

       POSIX-draft  ACL  semantics  can  be achieved with NFSv4 ACLs. However,
       only some NFSv4 ACLs can be translated to equivalent POSIX-draft ACLs.

       Permissions can be specified in three different chmod ACL formats: ver‐
       bose, compact, or positional. The verbose format uses words to indicate
       that the permissions are separated with a forward slash (/)  character.
       Compact  format  uses the permission letters and positional format uses
       the permission letters or the hyphen (-) to identify no permissions.

       The permissions for verbose mode and their abbreviated form  in  paren‐
       theses for compact and positional mode are described as follows:

       read_data (r)           Permission to read the data of the file

       list_directory (r)      Permission to list the contents of a directory.

       write_data (w)          Permission  to modify a file's data anywhere in
                               the file's  offset  range.  This  includes  the
                               ability  to grow the file or write to any arbi‐
                               trary offset.

       add_file (w)            Permission to add a new file to a directory.

       append_data (p)         The ability to modify the file's data, but only
                               starting  at EOF. Currently, this permission is
                               not supported.

       add_subdirectory (p)    Permission to create a subdirectory to a direc‐

       read_xattr (R)          The  ability to read the extended attributes of
                               a  file  or  do  a  lookup  in   the   extended
                               attributes directory.

       write_xattr (W)         The  ability  to  create extended attributes or
                               write to the extended attributes directory.

       execute (x)             Permission to execute a file.

       read_attributes (a)     The ability to read basic attributes (non-ACLs)
                               of  a  file. Basic attributes are considered to
                               be the stat  level  attributes.  Allowing  this
                               access  mask bit means that the entity can exe‐
                               cute ls(1) and stat(2).

       write_attributes (A)    Permission to change the times associated  with
                               a file or directory to an arbitrary value.

       delete (d)              Permission to delete the file.

       delete_child (D)        Permission to delete a file within a directory.

       read_acl (c)            Permission to read the ACL.

       write_acl (C)           Permission  to  write the ACL or the ability to
                               execute chmod(1).

       write_owner (o)         Permission to change the owner or  the  ability
                               to execute chown(1) or chgrp(1).

       synchronize (s)         Permission  to  access  a  file  locally at the
                               server with synchronous reads and writes.  Cur‐
                               rently, this permission is not supported.

       The following inheritance flags are supported by NFSv4:

       file_inherit (f)          Inherit  to  all  newly  created  files  in a

       dir_inherit (d)           Inherit to all newly created directories in a

       inherit_only (i)          Placed  on a directory, but does not apply to
                                 the directory itself, only to  newly  created
                                 created  files  and  directories.  This  flag
                                 requires file_inherit and or  dir_inherit  to
                                 indicate what to inherit.

       no_propagate (n)          Placed  on directories and indicates that ACL
                                 entries should only be inherited one level of
                                 the tree. This flag requires file_inherit and
                                 or dir_inherit to indicate what to inherit.

       successful_access (S))    Indicates if an alarm or audit record  should
                                 be  initiated  upon successful accesses. Used
                                 with audit/alarm ACE types.

       failed_access (F)         Indicates if an alarm or audit record  should
                                 be  initiated  when  access  fails. Used with
                                 audit/alarm ACE types.

       inherited (I)             ACE was inherited.

       -                         No permission granted.

       An NFSv4 ACL is expressed using the following syntax:


             owner@:<perms>[:inheritance flags]:<allow|deny>
             group@:<perms>[:inheritance flags]:<allow|deny>
             everyone@:<perms>[:inheritance flags]:<allow|deny>
             user:<username>[:inheritance flags]:<allow|deny>
             group:<groupname>[:inheritance flags]:<allow|deny>

             owner@:<perms>[:inheritance flags]:<successful_access|failed_access>:<audit|alarm>
             group@:<perms>[:inheritance flags]:<successful_access|failed_access>:<audit|alarm>
             everyone@:<perms>[:inheritance flags]:<successful_access|failed_access>:<audit|alarm>
             user:<perms>[:inheritance flags]:<successful_access|failed_access>:<audit|alarm>
             group:<perms>[:inheritance flags]:<successful_access|failed_access>:<audit|alarm>

       owner@    File owner

       group@    Group owner

       user      Permissions for a specific user

       group     Permissions for a specific group

       Permission and inheritance flags are separated by a / character.

       ACL specification examples:


       Using the compact ACL format, permissions are  specified  by  using  14
       unique letters to indicate permissions.

       Using  the  positional  ACL  format, permissions are specified as posi‐
       tional arguments similar to the ls -V format.  The  hyphen  (-),  which
       indicates  that no permission is granted at that position, can be omit‐
       ted and only the required letters have to be specified.

       The letters above are listed in the order they would  be  specified  in
       positional notation.

       With these letters you can specify permissions in the following equiva‐
       lent ways.


       Or you can remove the - and scrunch it together.


       The inheritance flags can also be specified in a more  compact  manner,
       as follows:


   Shell-level Solaris API
       The  Solaris  command  interface supports the manipulation of ACLs. The
       following Solaris utilities accommodate both ACL models:

       chmod       The chmod utility has been enhanced to allow for  the  set‐
                   ting  and  deleting  of ACLs. This is achieved by extending
                   the symbolic-mode argument to support ACL manipulation. See
                   chmod(1) for details.

       compress    When a file is compressed any ACL associated with the orig‐
                   inal file is preserved with the compressed file.

       cp          By default, cp ignores ACLs, unless the -p option is speci‐
                   fied.  When -p is specified the owner and group id, permis‐
                   sion  modes,  modification  and  access  times,  ACLs,  and
                   extended attributes if applicable are preserved.

       cpio        ACLs are preserved when the -P option is specified.

       find        Find  locates  files with ACLs when the -acl flag is speci‐

       ls          By default ls does not display ACL information. When the -v
                   option is specified, a file's ACL is displayed.

       mv          When a file is moved, all attributes are carried along with
                   the renamed file. When a file is moved across a file system
                   boundary,  the  ACLs are replicated. If the ACL information
                   cannot be replicated, the move fails and the source file is
                   not removed.

       pack        When a file is packed, any ACL associated with the original
                   file is preserved with the packed file.

       rcp         rcp has been enhanced to support copying. A file's  ACL  is
                   only preserved when the remote host supports ACLs.

       tar         ACLs are preserved when the -p option is specified.

       unpack      When  a  file  with  an  ACL is unpacked, the unpacked file
                   retains the ACL information.

   Application-level API
       The primary interfaces required to access file system ACLs at the  pro‐
       grammatic  level are the acl_get() and acl_set() functions. These func‐
       tions support both POSIX draft ACLs and NFSv4 ACLs.

   Audit ACE Types
       Where audit ACE types are supported, processes are required to have the
       PRIV_FILE_AUDIT privilege in order to view and set audit ACL entries.

       When retrieving an ACL, audit entries are skipped and not returned to a
       caller who lacks appropriate privilege.

       When an unprivileged process successfully sets  a  file  ACL,  existing
       audit  ACL  entries  for  the file are preserved, although they are not
       visible to that process. Attempting to set an ACL which contains  audit
       entries  will result in an error if the caller lacks appropriate privi‐

   ACL size limits
       Unprivileged  processes  have  a  limit   of   setting   a   total   of
       MAX_ACL_ENTRIES  combined allow/deny entries in an ACL. Privileged pro‐
       cesses may also set up to MAX_ACL_ENTRIES audit entries. Thus a  privi‐
       leged caller will observe a limit of 2 * MAX_ACL_ENTRIES total entries,
       while unprivileged users will observe a limit of  just  MAX_ACL_ENTRIES
       total entries.

   Retrieving a file's ACL
         int acl_get(const char *path, int flag, acl_t **aclp);
         int facl_get(int fd, int flag, acl_t **aclp);

       The  acl_get(3SEC)  and  facl_get(3SEC) functions retrieves an ACL on a
       file whose name is given  by  path  or  referenced  by  the  open  file
       descriptor fd. The flag argument specifies whether a trivial ACL should
       be retrieved. When the flag argument equals  ACL_NO_TRIVIAL  then  only
       ACLs  that  are  not  trivial are retrieved. The ACL is returned in the
       aclp argument.

   Freeing ACL structure
         void acl_free(acl_t *aclp)s;

       The acl_free() function frees up  memory  allocated  for  the  argument

   Setting an ACL on a file
         int acl_set(const char *path, acl_t *aclp);
         int facl_set(int fd, acl_t *aclp);

       The  acl_set(3SEC) and facl_get(3SEC) functions are used for setting an
       ACL on a file whose name is given by path or  referenced  by  the  open
       file  descriptor  fd.  The  aclp argument specifies the ACL to set. The
       acl_set(3SEC) translates an POSIX-draft ACL into a NFSv4 ACL  when  the
       target  file  systems  supports NFSv4 ACLs. No translation is performed
       when trying to set an NFSv4 ACL on a  POSIX-draft  ACL  supported  file

   Determining an ACL's trivialness
         int acl_trivial(const char *path);

       The  acl_trivial()  function  is used to determine whether a file has a
       trivial ACL. Whether an ACL is trivial depends on the type of the  ACL.
       A POSIX draft ACL is nontrivial if it has greater than MIN_ACL_ENTRIES.
       An NFSv4/ZFS-style ACL is nontrivial if it  either  has  entries  other
       than  owner@,  group@,  and everyone@, has inheritance flags set, or is
       not ordered in a manner that meets POSIX access control requirements.

   Removing all ACLs from a file
         int acl_strip(const char *path, uid_t uid, gid_t gid, mode_t mode);

       The acl_strip() function removes all ACLs from a file and replaces them
       with  a  trivial  ACL  based  off of the passed in argument mode. After
       replacing the ACL the owner and group of the file are set to the values
       specified in the uid and gid parameters.

   Converting ACLs to/from external representation
         int acl_fromtext(const char *path, acl_t **aclp);
         char *acl_totext(acl_t *aclp, int flags);

       The acl_text() function converts an internal ACL representation pointed
       to by aclp into an external representation. See DESCRIPTION for details
       about external representation.

       The  acl_fromtext() functions converts and external representation into
       an internal representation. See DESCRIPTION for details about  external

       The  following  examples demonstrate how the API can be used to perform
       basic operations on ACLs.

       Example 1 Retrieving and Setting an ACL

       Use the following to retrieve an ACL and set it on another file:

         error = acl_get("file", ACL_NO_TRIVIAL, &aclp);

         if (error == 0 && aclp != NULL) {
         error = acl_set("file2", aclp)

       Example 2 Retrieving and Setting Any ACLs

       Use the following to retrieve any ACL, including trivial ACLs, and  set
       it on another file:

         error = acl_get("file3", 0, &aclp);
         if (error == 0) {
         error = acl_set("file4", aclp)

       Example 3 Determining if a File has a Trivial ACL

       Use the following to determine if a file has a trivial ACL:

         istrivial = acl_trivial("file")

         if (istrivial == 0)
         printf("file %s has a trivial ACL\n", file);
         printf("file %s has a NON-trivial ACL\n", file);

       Example 4 Removing all ACLs from a File

       Use  the  following to remove all ACLs from a file, and set a new mode,
       owner, and group:

         error = acl_strip("file", 10, 100, 0644);

       chgrp(1), chmod(1), chown(1), cp(1), cpio(1),  find(1),  ls(1),  mv(1),
       tar(1),  acl(2), chmod(2), stat(2), acl_free(3SEC), acl_fromtext(3SEC),
       acl_get(3SEC), acl_strip(3SEC), acl_trivial(3SEC), aclsort(3SEC)

Oracle Solaris 11.4               15 Apr 2019                           acl(7)
맨 페이지 내용의 저작권은 맨 페이지 작성자에게 있습니다.