Subject: new ACL text

From: Mike Kupfer <[email-masked]>
Date: Fri, 02 Aug 2002 11:32:45 -0700

Here's a new draft of the ACL text.  It includes the formatting
changes from the latest I-D, and it incorporates the feedback I got
from Dave Noveck.  Change bars are relative to the text I sent out on
16 July and do not include the formatting changes.

mike

5.9.  Access Control Lists

   The NFS ACL attribute is an array of access control entries (ACE).
   There are various access control entry types, as defined in Section
   5.9.1.  The server is able to communicate which ACE types are
   supported by returning the appropriate value within the aclsupport
   attribute.  	Each ACE covers one or more operations on a file or
   directory as described in 5.9.2.  It may also contain one or more
   flags that modify the symantics of the ACE as defiend in Section
   5.9.3.

   The NFS ACE attribute is defined as follows:

   typedef uint32_t        acetype4;
   typedef uint32_t        aceflag4;
   typedef uint32_t        acemask4;

   struct nfsace4 {
           acetype4        type;
           aceflag4        flag;
           acemask4        access_mask;
           utf8string      who;
   };

   To determine if a request succeeds, each nfsace4 entry is processed	    |
   in order by the server.  Only ACEs which have a "who" that matches
   the requester are considered.  Each ACE is processed until all of
   the bits of the requester's access have been ALLOWED.  Once a bit
   (see below) has been ALLOWED by an ACCESS_ALLOWED_ACE, it is no
   longer considered in the processing of later ACEs. If an
   ACCESS_DENIED_ACE is encountered where the requester's mode still
   has unALLOWED bits in common with the "access_mask" of the ACE, the
   request is denied.

   The NFS ACL model is quite rich.  Some server platforms may provide	    |
   access control functionality that goes beyond the Unix-style mode
   attribute, but which is not as rich as the NFS ACL model.  So that
   users can take advantage of this more limited functionality, the
   server may indicate that it supports ACLs as long as it follows the	    |
   guidelines for mapping between its ACL model and the NFS ACL model.

   The situation is complicated by the fact that a server may have
   multiple modules that enforce ACLs.  For example, the enforcement
   for NFS access may be handled different from the enforcement for	    |
   local access, and both may be different from the enforcement for	    |
   access through other protocols such as SMB.  So it may be useful
   for a server to accept an ACL even if not all of its modules are
   able to support it.

   The guiding principle in all cases is that the server must not	    |
   accept ACLs that appear to make the file more secure than it really
   is.

5.9.1.  ACE type

   Type         Description
   _____________________________________________________
   ALLOW
                Explicitly grants the access defined in
                acemask4 to the file or directory.

   DENY
                Explicitly denies the access defined in
                acemask4 to the file or directory.

   AUDIT
                LOG (system dependent) any access
                attempt to a file or directory which
                uses any of the access methods specified
                in acemask4.

   ALARM
                Generate a system ALARM (system
                dependent) when any access attempt is
                made to a file or directory for the
                access methods specified in acemask4.

   A server need not support all of the above ACE types.  The bitmask
   constants used to represent the above definitions within the
   aclsupport attribute are as follows:

   const ACL4_SUPPORT_ALLOW_ACL    = 0x00000001;
   const ACL4_SUPPORT_DENY_ACL     = 0x00000002;
   const ACL4_SUPPORT_AUDIT_ACL    = 0x00000004;
   const ACL4_SUPPORT_ALARM_ACL    = 0x00000008;

   The semantics of the "type" field follow the descriptions provided
   above.

   The constants used for the type field (acetype4) are as follows:

   const ACE4_ACCESS_ALLOWED_ACE_TYPE      = 0x00000000;
   const ACE4_ACCESS_DENIED_ACE_TYPE       = 0x00000001;
   const ACE4_SYSTEM_AUDIT_ACE_TYPE        = 0x00000002;
   const ACE4_SYSTEM_ALARM_ACE_TYPE        = 0x00000003;

   Clients should not attempt to set an ACE unless the server claims
   support for that ACE type.  If the server receives a request to set
   an ACE that it cannot store, it must reject the request with
   NFS4ERR_ATTRNOTSUPP.							    |

   If the server receives a request to set an ACE that it can store
   but cannot enforce, the server SHOULD reject the request.		    |

   Example: suppose a server can enforce NFS ACLs for NFS access but
   cannot enforce ACLs for local access.  If arbitrary processes can
   run on the server, then the server SHOULD NOT indicate ACL support.	    |
   On the other hand, if only trusted administrative programs run
   locally, then the server may indicate ACL support.			    |

5.9.2.  ACE Access Mask

   The access_mask field contains values based on the following:

   Access                 Description
   _______________________________________________________________
   READ_DATA
                          Permission to read the data of the file
   LIST_DIRECTORY
                          Permission to list the contents of a
                          directory
   WRITE_DATA
                          Permission to modify the file's data
   ADD_FILE
                          Permission to add a new file to a
                          directory
   APPEND_DATA
                          Permission to append data to a file
   ADD_SUBDIRECTORY
                          Permission to create a subdirectory to a
                          directory
   READ_NAMED_ATTRS
                          Permission to read the named attributes
                          of a file
   WRITE_NAMED_ATTRS
                          Permission to write the named attributes
                          of a file
   EXECUTE
                          Permission to execute a file
   DELETE_CHILD
                          Permission to delete a file or directory
                          within a directory
   READ_ATTRIBUTES
                          The ability to read basic attributes
                          (non-acls) of a file
   WRITE_ATTRIBUTES
                          Permission to change basic attributes
                          (non-acls) of a file

   DELETE
                          Permission to Delete the file
   READ_ACL
                          Permission to Read the ACL
   WRITE_ACL
                          Permission to Write the ACL
   WRITE_OWNER
                          Permission to change the owner
   SYNCHRONIZE
                          Permission to access file locally at the
                          server with synchronous reads and writes

   The bitmask constants used for the access mask field are as follows:

   const ACE4_READ_DATA            = 0x00000001;
   const ACE4_LIST_DIRECTORY       = 0x00000001;
   const ACE4_WRITE_DATA           = 0x00000002;
   const ACE4_ADD_FILE             = 0x00000002;
   const ACE4_APPEND_DATA          = 0x00000004;
   const ACE4_ADD_SUBDIRECTORY     = 0x00000004;
   const ACE4_READ_NAMED_ATTRS     = 0x00000008;
   const ACE4_WRITE_NAMED_ATTRS    = 0x00000010;
   const ACE4_EXECUTE              = 0x00000020;
   const ACE4_DELETE_CHILD         = 0x00000040;
   const ACE4_READ_ATTRIBUTES      = 0x00000080;
   const ACE4_WRITE_ATTRIBUTES     = 0x00000100;
   const ACE4_DELETE               = 0x00010000;
   const ACE4_READ_ACL             = 0x00020000;
   const ACE4_WRITE_ACL            = 0x00040000;
   const ACE4_WRITE_OWNER          = 0x00080000;
   const ACE4_SYNCHRONIZE          = 0x00100000;

   Server implementations need not provide the granularity of control
   that is implied by this list of masks.  For example, POSIX-based
   systems might not distinguish APPEND_DATA (the ability to append to
   a file) from WRITE_DATA (the ability to modify existing contents);
   both masks would be tied to a single ``write'' permission.  When
   such a server returns attributes to the client, it would show both
   APPEND_DATA and WRITE_DATA if and only if the write permission is
   enabled.

   If a server receives a SETATTR request that it cannot accurately
   implement, it should err in the direction of more restricted
   access.  For example, suppose a server cannot distinguish
   overwriting data from appending new data, as described in the
   previous paragraph.  If a client submits an ACE where APPEND_DATA
   is set but WRITE_DATA is not (or vice versa), the server should
   reject the request with NFS4ERR_ATTRNOTSUPP.  Nonetheless, if the	    |
   ACE has type DENY, the server may silently turn on the other bit,
   so that both APPEND_DATA and WRITE_DATA are denied.

5.9.3.  ACE flag

   The "flag" field contains values based on the following descriptions.

   ACE4_FILE_INHERIT_ACE

   Can be placed on a directory and indicates that this ACE should be
   added to each new non-directory file created.

   ACE4_DIRECTORY_INHERIT_ACE

   Can be placed on a directory and indicates that this ACE should be
   added to each new directory created.

   ACE4_INHERIT_ONLY_ACE

   Can be placed on a directory but does not apply to the directory,
   only to newly created files/directories as specified by the above two
   flags.

   ACE4_NO_PROPAGATE_INHERIT_ACE

   Can be placed on a directory. Normally when a new directory is
   created and an ACE exists on the parent directory which is marked
   ACL4_DIRECTORY_INHERIT_ACE, two ACEs are placed on the new directory.
   One for the directory itself and one which is an inheritable ACE for
   newly created directories.  This flag tells the server to not place
   an ACE on the newly created directory which is inheritable by
   subdirectories of the created directory.

   ACE4_SUCCESSFUL_ACCESS_ACE_FLAG

   ACE4_FAILED_ACCESS_ACE_FLAG

   Both indicate for AUDIT and ALARM which state to log the event.  On
   every ACCESS or OPEN call which occurs on a file or directory which
   has an ACL that is of type ACE4_SYSTEM_AUDIT_ACE_TYPE or
   ACE4_SYSTEM_ALARM_ACE_TYPE, the attempted access is compared to the
   ace4mask of these ACLs. If the access is a subset of ace4mask and the
   identifier match, an AUDIT trail or an ALARM is generated.  By
   default this happens regardless of the success or failure of the
   ACCESS or OPEN call.

   The flag ACE4_SUCCESSFUL_ACCESS_ACE_FLAG only produces the AUDIT or
   ALARM if the ACCESS or OPEN call is successful. The
   ACE4_FAILED_ACCESS_ACE_FLAG causes the ALARM or AUDIT if the ACCESS
   or OPEN call fails.

   ACE4_IDENTIFIER_GROUP

   Indicates that the "who" refers to a GROUP as defined under Unix.

   The bitmask constants used for the flag field are as follows:

   const ACE4_FILE_INHERIT_ACE             = 0x00000001;
   const ACE4_DIRECTORY_INHERIT_ACE        = 0x00000002;
   const ACE4_NO_PROPAGATE_INHERIT_ACE     = 0x00000004;
   const ACE4_INHERIT_ONLY_ACE             = 0x00000008;
   const ACE4_SUCCESSFUL_ACCESS_ACE_FLAG   = 0x00000010;
   const ACE4_FAILED_ACCESS_ACE_FLAG       = 0x00000020;
   const ACE4_IDENTIFIER_GROUP             = 0x00000040;

   A server need not support any of these flags.  If the server
   supports flags that are similar to, but not exactly the same as,
   these flags, the implementation may define a mapping between the
   protocol-defined flags and the implementation-defined flags.
   Again, the guiding principle is that the file not appear to be more
   secure than it really is.

   For example, suppose a client tries to set an ACE with
   ACE4_FILE_INHERIT_ACE set but not ACE4_DIRECTORY_INHERIT_ACE.  If
   the server does not support any form of ACL inheritance, the server
   should reject the request with NFS4ERR_ATTRNOTSUPP.  If the server	    |
   supports a single "inherit ACE" flag that applies to both files and
   directories, the server may reject the request (i.e., requiring the
   client to set both the file and directory inheritance flags).  The
   server may also accept the request and silently turn on the
   ACE4_DIRECTORY_INHERIT_ACE flag.

5.9.4.  ACE who

   There are several special identifiers ("who") which need to be
   understood universally, rather than in the context of a particular
   DNS domain. Some of these identifiers cannot be understood when an
   NFS client accesses the server, but have meaning when a local
   process accesses the file. The ability to display and modify these
   permissions is permitted over NFS, even if none of the access
   methods on the server understands the identifiers.

   Who                    Description
   _______________________________________________________________
   "OWNER"
                          The owner of the file.
   "GROUP"
                          The group associated with the file.
   "EVERYONE"
                          The world.
   "INTERACTIVE"
                          Accessed from an interactive terminal.
   "NETWORK"
                          Accessed via the network.
   "DIALUP"
                          Accessed as a dialup user to the server.
   "BATCH"
                          Accessed from a batch job.
   "ANONYMOUS"
                          Accessed without any authentication.
   "AUTHENTICATED"
                          Any authenticated user (opposite of
                          ANONYMOUS)
   "SERVICE"
                          Access from a system service.

   To avoid conflict, these special identifiers are distinguish by an
   appended "@" and should appear in the form "xxxx@" (note: no domain
   name after the "@").  For example: ANONYMOUS@.

---

From: Benny Halevy <[email-masked]>
Date: Sat, 3 Aug 2002 19:14:51 -0700 (PDT)

Mike,

As I read it, the text is still not clear about the
issue of having both ACLs and file mode (Unix style
permissions).  Currently the only reference I could
find to this subject is in Section 5.5 saying
&#34;Unix-style permission bits for this object
(deprecated in favor of ACLs)&#34;.  The issue was
discussed recently in 
a thread called &#34;Interaction between mode bits and
acls&#34; (see
http://playground.sun.com/pub/nfsv4/nfsv4-wg-archive/2002/0157.html)
yet I believe it deserves some elaboration.

If the interaction between conflicting ACE's and mode
bits is undefined and left open to the server then the
spec should say so.  Recommended guidelines could be
useful too :-)

When an ACL is defined for a file, what should be the
result of local stat()/chmod() or GETATTR/SETATTR when
the file is exported also in NFSv[23]?  The
interesting cases are:
ACL is defined for the file and -
a. The file has no mode attribute.
b. The file has a mode attribute.

Thanks,

Benny

--- Mike Kupfer &lt;[email-masked]&gt;
wrote:
&gt; Here's a new draft of the ACL text.  It includes
the
&gt; formatting
&gt; changes from the latest I-D, and it incorporates
the
&gt; feedback I got
&gt; from Dave Noveck.  Change bars are relative to
the
&gt; text I sent out on
&gt; 16 July and do not include the formatting
changes.
&gt; 
&gt; mike
&gt; 
&gt; 5.9.  Access Control Lists
&gt; 
&gt;    The NFS ACL attribute is an array of access
&gt; control entries (ACE).
&gt;    There are various access control entry types,
as
&gt; defined in Section
&gt;    5.9.1.  The server is able to communicate
which
&gt; ACE types are
&gt;    supported by returning the appropriate value
&gt; within the aclsupport
&gt;    attribute.  	Each ACE covers one or more
&gt; operations on a file or
&gt;    directory as described in 5.9.2.  It may also
&gt; contain one or more
&gt;    flags that modify the symantics of the ACE as
&gt; defiend in Section
&gt;    5.9.3.
&gt; 
&gt;    The NFS ACE attribute is defined as follows:
&gt; 
&gt;    typedef uint32_t        acetype4;
&gt;    typedef uint32_t        aceflag4;
&gt;    typedef uint32_t        acemask4;
&gt; 
&gt;    struct nfsace4 {
&gt;            acetype4        type;
&gt;            aceflag4        flag;
&gt;            acemask4        access_mask;
&gt;            utf8string      who;
&gt;    };
&gt; 
&gt;    To determine if a request succeeds, each
nfsace4
&gt; entry is processed	    |
&gt;    in order by the server.  Only ACEs which have
a
&gt; &#34;who&#34; that matches
&gt;    the requester are considered.  Each ACE is
&gt; processed until all of
&gt;    the bits of the requester's access have been
&gt; ALLOWED.  Once a bit
&gt;    (see below) has been ALLOWED by an
&gt; ACCESS_ALLOWED_ACE, it is no
&gt;    longer considered in the processing of later
&gt; ACEs. If an
&gt;    ACCESS_DENIED_ACE is encountered where the
&gt; requester's mode still
&gt;    has unALLOWED bits in common with the
&gt; &#34;access_mask&#34; of the ACE, the
&gt;    request is denied.
&gt; 
&gt;    The NFS ACL model is quite rich.  Some server
&gt; platforms may provide	    |
&gt;    access control functionality that goes beyond
the
&gt; Unix-style mode
&gt;    attribute, but which is not as rich as the NFS
&gt; ACL model.  So that
&gt;    users can take advantage of this more limited
&gt; functionality, the
&gt;    server may indicate that it supports ACLs as
long
&gt; as it follows the	    |
&gt;    guidelines for mapping between its ACL model
and
&gt; the NFS ACL model.
&gt; 
&gt;    The situation is complicated by the fact that
a
&gt; server may have
&gt;    multiple modules that enforce ACLs.  For
example,
&gt; the enforcement
&gt;    for NFS access may be handled different from
the
&gt; enforcement for	    |
&gt;    local access, and both may be different from
the
&gt; enforcement for	    |
&gt;    access through other protocols such as SMB. 
So
&gt; it may be useful
&gt;    for a server to accept an ACL even if not all
of
&gt; its modules are
&gt;    able to support it.
&gt; 
&gt;    The guiding principle in all cases is that the
&gt; server must not	    |
&gt;    accept ACLs that appear to make the file more
&gt; secure than it really
&gt;    is.
&gt; 
&gt; 5.9.1.  ACE type
&gt; 
&gt;    Type         Description
&gt;   
&gt;
_____________________________________________________
&gt;    ALLOW
&gt;                 Explicitly grants the access
defined
&gt; in
&gt;                 acemask4 to the file or
directory.
&gt; 
&gt;    DENY
&gt;                 Explicitly denies the access
defined
&gt; in
&gt;                 acemask4 to the file or
directory.
&gt; 
&gt;    AUDIT
&gt;                 LOG (system dependent) any access
&gt;                 attempt to a file or directory
which
&gt;                 uses any of the access methods
&gt; specified
&gt;                 in acemask4.
&gt; 
&gt;    ALARM
&gt;                 Generate a system ALARM (system
&gt;                 dependent) when any access
attempt
&gt; is
&gt;                 made to a file or directory for
the
&gt;                 access methods specified in
&gt; acemask4.
&gt; 
&gt;    A server need not support all of the above ACE
&gt; types.  The bitmask
&gt;    constants used to represent the above
definitions
&gt; within the
&gt;    aclsupport attribute are as follows:
&gt; 
&gt;    const ACL4_SUPPORT_ALLOW_ACL    = 0x00000001;
&gt;    const ACL4_SUPPORT_DENY_ACL     = 0x00000002;
&gt;    const ACL4_SUPPORT_AUDIT_ACL    = 0x00000004;
&gt;    const ACL4_SUPPORT_ALARM_ACL    = 0x00000008;
&gt; 
&gt;    The semantics of the &#34;type&#34; field
follow the
&gt; descriptions provided
&gt;    above.
&gt; 
&gt;    The constants used for the type field
(acetype4)
&gt; are as follows:
&gt; 
&gt;    const ACE4_ACCESS_ALLOWED_ACE_TYPE      =
&gt; 0x00000000;
&gt;    const ACE4_ACCESS_DENIED_ACE_TYPE       =
&gt; 0x00000001;
&gt;    const ACE4_SYSTEM_AUDIT_ACE_TYPE        =
&gt; 0x00000002;
&gt;    const ACE4_SYSTEM_ALARM_ACE_TYPE        =
&gt; 0x00000003;
&gt; 
&gt;    Clients should not attempt to set an ACE
unless
&gt; the server claims
&gt;    support for that ACE type.  If the server
&gt; receives a request to set
&gt;    an ACE that it cannot store, it must reject
the
&gt; request with
&gt;    NFS4ERR_ATTRNOTSUPP.							    |
&gt; 
&gt;    If the server receives a request to set an ACE
&gt; that it can store
&gt;    but cannot enforce, the server SHOULD reject
the
&gt; request.		    |
&gt; 
&gt;    Example: suppose a server can enforce NFS ACLs
&gt; for NFS access but
&gt;    cannot enforce ACLs for local access.  If
&gt; arbitrary processes can
&gt;    run on the server, then the server SHOULD NOT
&gt; indicate ACL support.	    |
&gt;    On the other hand, if only trusted
administrative
&gt; programs run
&gt;    locally, then the server may indicate ACL
&gt; support.			    |
&gt; 
&gt; 
&gt; 5.9.2.  ACE Access Mask
&gt; 
&gt;    The access_mask field contains values based on
&gt; the following:
&gt; 
&gt;    Access                 Description
&gt;   
&gt;
_______________________________________________________________
&gt;    READ_DATA
&gt;                           Permission to read the
&gt; data of the file
&gt;    LIST_DIRECTORY
&gt;                           Permission to list the
&gt; contents of a
&gt;                           directory
&gt;    WRITE_DATA
&gt;                           Permission to modify
the
&gt; file's data
&gt;    ADD_FILE
&gt;                           Permission to add a new
&gt; file to a
&gt;                           directory
&gt;    APPEND_DATA
&gt;                           Permission to append
data
&gt; to a file
&gt;    ADD_SUBDIRECTORY
&gt;                           Permission to create a
&gt; subdirectory 
=== message truncated ===

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 7 Aug 2002 23:06:14 -0500

I should point out that issue 211 that was resolved in the last update
addresses some of these questions and should be complete at this point.