Subject: [nfsv4] Consensus from ACL meeting and additional raw notes

From: Lisa Week <[email-masked]>
Date: Mon, 14 Aug 2006 11:56:29 -0600

Hi,

Here are the remaining raw notes and a quick summary of the consensus 
reached in the meeting.

Thanks,
Lisa

Final consensus of the "ACL Design Team" was:
------------------------------------------
Continue with the design and text as specified in the file uploaded to 
Issue #93 named acl.txt 
(http://www.nfsv4-editor.org/cgi-bin/roundup/nfsv4/issue93) and pursue 
an easier to determine mask (i.e. rather than relying on interpreting 
the access mask bits in DENY ACEs).

The text in Issue #93 will be modified based on the review of the 
document in the meeting and will be provided to Spencer for inclusion in 
the next rev of the minor version draft.  See the attached text for the 
intended changes.

There was no decision made on how the easier to determine mask proposal 
would move forward.  This is still an open issue.  We will work toward a 
plan.

========================

Raw Notes:

Raw notes from Wednesday (8/102006), discussion about the major 
contention points and some of the arguments on both sides:

1.) Changing the ACL based on the mode bits being set (SETATTR of mode):

Option 1: Write through to the ACL
(Specified in the minor version draft)
----------------------------------------------
1.) Simpler mode application algorithm, if we insist on POSIX 
first-match semantics and accept any NFSv4 ACL.
2.) RFC3530 compliant
ZFS
3.) User Requests / Customers (Sun and EMC) have said that they want the 
mode and ACL to say in sync.

Option 2: No-write through
(setting owner, owner_group and other will not happen upon SETATTR of mode)
------------------------------------
1.) If a sequence of chmod's is a no-op, it is also a no-op on the ACL.
2.) Gives POSIX draft ACL behavior:
Linux ext2/3
UFS on Solaris
BSDs, IRIX, ...
3.) Linux Acceptance ?

The argument for no-write through is that write-through potentially 
elevates the permission on any "GROUP@" ACEs in the ACL, thus 
introducing a security hole.

Counter argument:
1.) The fact that a SETATTR of the mode changes the permissions of the 
owning group to what the mode being set says they should be is not a 
security hole

2.) If you really want to deny any capabilities to a specific group, you 
should NOT use a GROUP@ ACE because the value of the group that the 
GROUP@ can and will change with a chown to a different group (chgrp command)

2.) How to calculate the mode bits from an ACL:

Option 1: They are an upper bound
------------------------------------------------
Only without write-through will it ensure that stat() returns the result 
of chmod()

Option 2: Based on u, g, o (OWNER@, GROUP@ and EVERYONE@ ACEs)
(Specified in minor version draft)
----------------------------------------
1.) With write-through ensures stat() after chmod() returns the mode 
that was set.
2.) More NFSv2 Friendly ???????

Mario: Does it really matter? Hopefully mode bits as a permission model 
will go away...NFSv4 has revived the thought that applications must 
support ACLs...

3.) How do we mask

Option 1: Only with new protocol
--------------------------------------------
Simpler implementation
Less "guesswork" which would incorrectly weaken DENYs

Option 2: Use existing protocol (i.e. DENY ACEs)
(Specified in minor version draft)
------------------------------------------
Preserves more information in many cases

                  |  upper-bound         | U, G, O
------------------|----------------------|------------------
write-through     |     OK                  | stat, chmod (changes the ACL)
------------------|----------------------|------------------
no write-through  |  without mask         | stat chmod (changes the ACL)
                   chmod, stat                         | chmod, stat 
(gives different
                   (gives different mode)|              mode)

Bruce's preference on the major design points:
1.) Changing the ACL based on the mode bits being set (SETATTR of mode):
Go with Option 1: Write through to the ACL
2.) How to calculate the mode bits from an ACL:
Go with Option 2: Based on u, g, o (OWNER@, GROUP@ and EVERYONE@ ACEs)
3.) How do we mask
Go with Option 1: Only with new protocol

Bruce recommended proposing this via the Linux community and see what 
happens.
Andreas agreed.

===========================

Review of the document:
Some small and other large changes were requested to be made to the 
document by Bruce and Andreas.  See the attached document for comments 
from Bruce and Andreas (search for "<comment>").

Remaining open issues on the document changes discussed:
1.) Section 1.1.  Goals
* There are multiple bullet items in the goals section that need the 
text to be finalized.
2.) Section 1.4.1.1.  Setting mode and not ACL
* More discussion needs to go into the decision of whether or not we 
should change the MAY to a SHOULD in:    "Access mask bits other those 
listed above, appearing in ALLOW ACEs, MAY also be disabled."
3.) Section 1.4.3.  Creating New Objects
* Research into the Windows behavior needs to happen in order to 
determine how to specify what behavior we should specify when creating 
an object when just an ACL is given.

====================

The following is a summary of a discussion held on Wednesday (8/9/2006):

Sam lead a discussion on how we could try for a more Windows friendly 
ordering upon setting of a mode (using the methods as currently 
specified in NFSv4.1):

1.) Delete DENY and ALLOW ACEs with who of O@, G@, E@
2.) Determine which ACEs are masks and delete them
3.) Determine new mask ACE DENY and ALLOW sections
4.) concat.

D0: OWNER@  [!USR & (GRP | OTH)]
A0: OWNER@  [USR & !GRP & OTH]   <--This would only be required in a
D1: GROUP@  [!GRP]     situation where the mode being set
    is something like 707.
mask
old ACL
A1: OWNER@  [*USR]
A2: GROUP@  [*GRP]
A3: EVERYONE@  [*OTH]
inherited

------

So, how do we do the masks:
* We have a mask attribute
* We use DENY ACEs

Arguments against a mask attribute:
Windows servers (i.e. Hummingbird) will never be able to support a mask 
attribute.  Therefore, the Hummingbird server would HAVE to use DENY 
ACEs in order to get the mask behaviors.

Concerns about using DENY ACEs:
Bruce is (very) worried about parsing an ACL and trying to determine 
which DENY ACEs are masks.

Bruce: Is able to accept the fact that we may have to play with DENY 
ACEs....but is not able to accept the fact that this is our future 
direction.  Bruce would like a mask outside of using the DENY ACEs.

When clients don't support masks (and don't request it) how does that 
interact with clients that do support mask attributes?

Bruce:
We could just not expose the mask as an NFSv4 Attribute.  Have that be 
an internal server side only attribute.  Then the server can do what it 
needs to in the face of a setacl and multiple chmods.  Then the server 
can choose whether to turn off bits or to use DENY aces in order to 
effectively turn off bits.

Andreas argues that if you could provide the mask attribute to clients 
then why wouldn't you...

NFSv4                                                         S. Shepler
Internet-Draft                                                 M. Eisler
Expires: January 2, 2007                                       D. Noveck
                                                                 Editors
                                                               July 2006

                         NFSv4 Minor Version 1
                 draft-ietf-nfsv4-minorversion1-04.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 2, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This Internet-Draft describes NFSv4 minor version one, including
   features retained from the base protocol and protocol extensions made
   subsequently.  The current draft includes desciption of the major
   extensions, Sessions, Directory Delegations, and parallel NFS (pNFS).
   This Internet-Draft is an active work item of the NFSv4 working
   group.  Active and resolved issues may be found in the issue tracker
   at: http://www.nfsv4-editor.org/cgi-bin/roundup/nfsv4.  New issues

Shepler, et al.          Expires January 2, 2007                [Page 1]

Internet-Draft            NFSv4 Minor Version 1                July 2006

   related to this document should be raised with the NFSv4 Working
   Group [email-masked] and logged in the issue tracker.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [1].

Table of Contents

   1.  Access Control Lists . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Goals  . . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.2.  File Attributes Discussion . . . . . . . . . . . . . . . .  4
       1.2.1.  ACL Attribute  . . . . . . . . . . . . . . . . . . . .  4
       1.2.2.  mode Attribute . . . . . . . . . . . . . . . . . . . . 15
     1.3.  Common Methods . . . . . . . . . . . . . . . . . . . . . . 15
       1.3.1.  Interpreting an ACL  . . . . . . . . . . . . . . . . . 16
       1.3.2.  Computing a Mode Attribute from an ACL . . . . . . . . 18
     1.4.  Requirements . . . . . . . . . . . . . . . . . . . . . . . 20
       1.4.1.  Setting the mode and/or ACL Attributes . . . . . . . . 20
       1.4.2.  Retrieving the mode and/or ACL Attributes  . . . . . . 21
       1.4.3.  Creating New Objects . . . . . . . . . . . . . . . . . 22
   2.  Security Considerations  . . . . . . . . . . . . . . . . . . . 23
   3.  ACL Algorithm Examples . . . . . . . . . . . . . . . . . . . . 23
     3.1.  Recomputing mode upon SETATTR of ACL . . . . . . . . . . . 23
     3.2.  Computing the Inherited ACL  . . . . . . . . . . . . . . . 27
       3.2.1.  Discussion . . . . . . . . . . . . . . . . . . . . . . 28
     3.3.  Applying a Mode to an Existing ACL . . . . . . . . . . . . 28
   4.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
     4.1.  Normative References . . . . . . . . . . . . . . . . . . . 33
     4.2.  Informative References . . . . . . . . . . . . . . . . . . 34
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 34
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
   Intellectual Property and Copyright Statements . . . . . . . . . . 37

Shepler, et al.          Expires January 2, 2007                [Page 2]

Internet-Draft            NFSv4 Minor Version 1                July 2006

1.  Access Control Lists

   Access Control Lists (ACLs) are a file attribute that specify fine
   grained access control.  This chapter covers the "acl", "aclsupport",
   and "mode" file attributes, and their interactions.

1.1.  Goals

   ACLs and modes represent two well established but different models
   for specifying permissions.  This chapter specifies requirements that
   attempt to meet the following goals:

   o  If a server supports the mode attribute, it should provide
      reasonable semantics to clients that only set and retrieve the
      mode attribute.

<comment>
Initially there was lots of disagreement about the above bullet, but I don't know if it is really an issue anymore (Bruce? Andreas?)

Sam said that the above bullet is really supposed to mean that just setting the mode allows the modification of owner, owning group and other permissions with regard to read, write, execute...

Bruce and Andreas don't think that it should be specified by "SHOULD"....

Clients that only support the mode should display UNIX like behavior.

</comment>

   o  If a server supports the ACL attribute, it should provide
      reasonable semantics to clients that only set and retrieve the ACL
      attribute.

   o  On servers that support the mode attribute, if the ACL attribute
      has never been set on an object, via inheritance or explicitly,
      the behavior should be traditional UNIX-like behavior.

   o  On servers that support the mode attribute, if the ACL attribute
      has been previously set on an object, either explicitly or via
      inheritance:

      *  Setting only the mode attribute should effectively control the
         traditional UNIX-like permissions of read, write, and execute
         on owner, owner_group, and other.

<comment>
Bruce suggests to leave the above bullet out.
</comment>

      *  Setting only the mode attribute should provide reasonable
         security.  For example, setting a mode of 000 should be enough
         to ensure that future opens for read or write by any principal
         should fail, regardless of a previously existing or inherited
         ACL.  bruce suggests not allowing anything beyond the mode.

   o  It must be possible to implement a server such that its clients
      can have POSIX compliant semantics.

<comment>
Andreas thinks: if the server supports the mode attribute, they should have POSIX behaviors...
Bruce thinks the above bullet should be deleted.
</comment>

   o  This minor version of NFSv4 should not introduce significantly
      different semantics relating to the mode and ACL attributes, nor
      should it render invalid any existing conformant implementations.
      Rather, this chapter provides clarifications based on previous
      implementations and discussions around them.

Shepler, et al.          Expires January 2, 2007                [Page 3]

Internet-Draft            NFSv4 Minor Version 1                July 2006

   o  If a server supports the ACL attribute, then at any time, the
      server can provide an ACL attribute when requested.  The ACL
      attribute will describe all permissions on the file object, except
      for the three high-order bits of the mode attribute (described in
      Section 1.2.2).  The ACL attribute will not conflict with the mode
      attribute, on servers that support the mode attribute.

<comment>
On the above bullet:
There are exceptions, e.g. owner can always write ACL, read-only file systems, etc.
</comment>

   o  If a server supports the mode attribute, then at any time, the
      server can provide a mode attribute when requested.  The mode
      attribute will not conflict with the ACL attribute, on servers
      that support the ACL attribute.

<comment>
Don't know if this is still relevant (Bruce?)

Bruce's comment: mode bits independent of ACL; if both are in the same setattr, group bits could specify POSIX-draft mask.  group perm is in ACL, POSIX-draft ACL mask is in the group bits of the mode.
</comment>

   o  When a mode attribute is set on an object, the ACL attribute may
      need to be modified so as to not conflict with the new mode.  In
      such cases, it is desirable that the ACL keep as much information
      as possible.  This includes information about inheritance, AUDIT
      and ALARM ACEs, and permissions granted and denied that do not
      conflict with the new mode.

1.2.  File Attributes Discussion

1.2.1.  ACL Attribute

   The NFS version 4 ACL attribute is an array of access control entries
   (ACEs).  Although the client can read and write the ACL attribute,
   the server is responsible for using the ACL to perform access
   control.  The client can use the OPEN or ACCESS operations to check
   access without modifying or reading data or metadata.

   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;
                           utf8str_mixed  who;
                       };

   The NFS version 4 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 version 4

Shepler, et al.          Expires January 2, 2007                [Page 4]

Internet-Draft            NFSv4 Minor Version 1                July 2006

   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 version 4 access may be 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.

1.2.1.1.  ACE Type

   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;

   +------------------------------+--------------+---------------------+
   | Value                        | Abbreviation | Description         |
   +------------------------------+--------------+---------------------+
   | ACE4_ACCESS_ALLOWED_ACE_TYPE | ALLOW        | Explicitly grants   |
   |                              |              | the access defined  |
   |                              |              | in acemask4 to the  |
   |                              |              | file or directory.  |
   | ACE4_ACCESS_DENIED_ACE_TYPE  | DENY         | Explicitly denies   |
   |                              |              | the access defined  |
   |                              |              | in acemask4 to the  |
   |                              |              | file or directory.  |
   | ACE4_SYSTEM_AUDIT_ACE_TYPE   | AUDIT        | LOG (system         |
   |                              |              | dependent) any      |
   |                              |              | access attempt to a |
   |                              |              | file or directory   |
   |                              |              | which uses any of   |
   |                              |              | the access methods  |
   |                              |              | specified in        |
   |                              |              | acemask4.           |

Shepler, et al.          Expires January 2, 2007                [Page 5]

Internet-Draft            NFSv4 Minor Version 1                July 2006

   | ACE4_SYSTEM_ALARM_ACE_TYPE   | 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.           |
   +------------------------------+--------------+---------------------+

    The "Abbreviation" column denotes how the types will be referred to
                   throughout the rest of this document.

1.2.1.2.  The aclsupport Attribute

   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;

   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 with NFS4ERR_ATTRNOTSUPP.

   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.

1.2.1.3.  ACE Access Mask

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

Shepler, et al.          Expires January 2, 2007                [Page 6]

Internet-Draft            NFSv4 Minor Version 1                July 2006

              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;

   Throughout the rest of this document, access mask bits are often
   referred to without the leading "ACE4_"; for example, "READ_DATA"
   refers to the bit "ACE4_READ_DATA".

1.2.1.3.1.  Discussion of Mask Attributes

    ACE4_READ_DATA
       Operation(s) affected:
            READ
            OPEN
       Discussion:
            Permission to read the data of the file.

            Servers SHOULD allow a user the ability to read the data
            of the file when only the ACE4_EXECUTE access mask bit is
            allowed.

    ACE4_LIST_DIRECTORY
        Operation(s) affected:
            READDIR
        Discussion:
            Permission to list the contents of a directory.

    ACE4_WRITE_DATA
        Operation(s) affected:
            WRITE
            OPEN
<comment>
Add SETATTR of size attribute to this list.
</comment>

        Discussion:
            Permission to modify a file's data anywhere in the file's
            offset range.  This includes the ability to write to any

Shepler, et al.          Expires January 2, 2007                [Page 7]

Internet-Draft            NFSv4 Minor Version 1                July 2006

            arbitrary offset and as a result to grow the file.

    ACE4_ADD_FILE
        Operation(s) affected:
            CREATE
            OPEN
        Discussion:
            Permission to add a new file in a directory.  The CREATE
            operation is affected when nfs_ftype4 is NF4LNK, NF4BLK,
            NF4CHR, NF4SOCK, or NF4FIFO. (NF4DIR is not listed because
            it is covered by ACE4_ADD_SUBDIRECTORY.) OPEN is affected
            when used to create a regular file.

    ACE4_APPEND_DATA
        Operation(s) affected:
            WRITE
            OPEN
<comment>
Add SETATTR of size attribute (?) - Why is this questionable?
</comment>

        Discussion:
             The ability to modify a file's data, but only starting at
             EOF.  This allows for the notion of append-only files, by
             allowing ACE4_APPEND_DATA and denying ACE4_WRITE_DATA to
             the same user or group.  If a file has an ACL such as the
             one described above and a WRITE request is made for
             somewhere other than EOF, the server SHOULD return
             NFS4ERR_ACCESS.

    ACE4_ADD_SUBDIRECTORY
        Operation(s) affected:
            CREATE
        Discussion:
            Permission to create a subdirectory in a directory.  The
            CREATE operation is affected when nfs_ftype4 is NF4DIR.

    ACE4_READ_NAMED_ATTRS
        Operation(s) affected:
            OPENATTR
        Discussion:
            Permission to read the named attributes of a file or to
            lookup the named attributes directory.  OPENATTR is
            affected when it is not used to create a named attribute
            directory.  This is when 1.) createdir is TRUE, but a
            named attribute directory already exists, or 2.) createdir
            is FALSE.

    ACE4_WRITE_NAMED_ATTRS
        Operation(s) affected:
            OPENATTR
        Discussion:

Shepler, et al.          Expires January 2, 2007                [Page 8]

Internet-Draft            NFSv4 Minor Version 1                July 2006

            Permission to write the named attributes of a file or
            to create a named attribute directory.  OPENATTR is
            affected when it is used to create a named attribute
            directory.  This is when createdir is TRUE and no named
            attribute directory exists.  The ability to check whether
            or not a named attribute directory exists depends on the
            ability to look it up, therefore, users also need the
            ACE4_READ_NAMED_ATTRS permission in order to create a
            named attribute directory.

    ACE4_EXECUTE
        Operation(s) affected:
            LOOKUP
            READ
            OPEN
        Discussion:
            Permission to execute a file or traverse/search a
            directory.

            Servers SHOULD allow a user the ability to read the data
            of the file when only the ACE4_EXECUTE access mask bit is
            allowed.  This is because there is no way to execute a
            file without reading the contents.  Though a server may
            treat ACE4_EXECUTE and ACE4_READ_DATA bits identically
            when deciding to permit a READ operation, it SHOULD still
            allow the two bits to be set independently in ACLs, and
            MUST distinguish between them when replying to ACCESS
            operations.  In particular, servers SHOULD NOT silently
            turn on one of the two bits when the other is set, as
            that would make it impossible for the client to correctly
            enforce the distinction between read and execute
            permissions.

<comment>
Leave the following example in or take it out?
</comment>

             As an example, following a SETATTR of the following ACL:
                     nfsuser:ACE4_EXECUTE:ALLOW

             A subsequent GETATTR of ACL for that file SHOULD return:
                     nfsuser:ACE4_EXECUTE:ALLOW
             Rather than:
                     nfsuser:ACE4_EXECUTE/ACE4_READ_DATA:ALLOW

    ACE4_DELETE_CHILD
        Operation(s) affected:
            REMOVE
        Discussion:
            Permission to delete a file or directory within a
            directory.  See section "ACE4_DELETE vs.
            ACE4_DELETE_CHILD" for information on how these two access

Shepler, et al.          Expires January 2, 2007                [Page 9]

Internet-Draft            NFSv4 Minor Version 1                July 2006

            mask bits interact.

    ACE4_READ_ATTRIBUTES
        Operation(s) affected:
            GETATTR of file system object attributes
        Discussion:
            The ability to read basic attributes (non-ACLs) of a file.
            On a UNIX system, basic attributes can be thought of as
            the stat level attributes.  Allowing this access mask bit
            would mean the entity can execute "ls -l" and stat.

    ACE4_WRITE_ATTRIBUTES
        Operation(s) affected:
            SETATTR of time_access_set, time_backup,
            time_create, time_modify_set
<comment>
Add archive, mime_type, hidden, system (?)
Or should we just talk about which attributes are NOT covered by this?
</comment>

        Discussion:
            Permission to change the times associated with a file
            or directory to an arbitrary value.  A user having
            ACE4_WRITE_DATA permission, but lacking
            ACE4_WRITE_ATTRIBUTES must be allowed to implicitly set
            the times associated with a file.

    ACE4_DELETE
        Operation(s) affected:
            REMOVE
        Discussion:
            Permission to delete the file or directory.  See section
            "ACE4_DELETE vs. ACE4_DELETE_CHILD" for information on how
            these two access mask bits interact.
<comment>
Can we change the above "See section "ACE4_DELETE vs. ACE4_DELETE_CHILD" for information..." to "See section <number> for information..."?
</comment>

    ACE4_READ_ACL
        Operation(s) affected:
            GETATTR of acl
        Discussion:
            Permission to read the ACL.

    ACE4_WRITE_ACL
        Operation(s) affected:
            SETATTR of acl and mode
        Discussion:
            Permission to write the acl and mode attributes.

    ACE4_WRITE_OWNER
        Operation(s) affected:
            SETATTR of owner and owner_group
        Discussions:
            Permission to write the owner and owner_group attributes.
            On UNIX systems, this is the ability to execute chown or

Shepler, et al.          Expires January 2, 2007               [Page 10]

Internet-Draft            NFSv4 Minor Version 1                July 2006

            chgrp.
<comment>
In the above, we should discuss system calls rather than commands;  in this case it is all chown().
</comment>

    ACE4_SYNCHRONIZE
        Operation(s) affected:
            NONE
        Discussion:
            Permission to access file locally at the server with
            synchronized reads and writes.

   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 error 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.

1.2.1.3.2.  ACE4_DELETE vs. ACE4_DELETE_CHILD

   Two access mask bits govern the ability to delete a file or directory
   object: ACE4_DELETE on the object itself, and ACE4_DELETE_CHILD on
   the object's parent directory.

   Many systems also consult the "sticky bit" (MODE4_SVTX) and write
   mode bit on the parent directory when determining whether to allow a
   file to be deleted.  The mode bit for write corresponds to
   ACE4_WRITE_DATA, which is the same physical bit as ACE4_ADD_FILE.
   Therefore, ACE4_ADD_FILE can come into play when determining
   permission to delete.

   In the algorithm below, the strategy is that ACE4_DELETE and
   ACE4_DELETE_CHILD take precedence over the sticky bit, and the sticky
   bit takes precedence over the "write" mode bits (reflected in
   ACE4_ADD_FILE).

   Server implementations SHOULD grant or deny permission to delete
   based on the following algorithm.

Shepler, et al.          Expires January 2, 2007               [Page 11]

Internet-Draft            NFSv4 Minor Version 1                July 2006

       if ACE4_EXECUTE is denied by the parent directory ACL:
           deny delete
       else if ACE4_DELETE is allowed by the target object ACL:
           allow delete
       else if ACE4_DELETE_CHILD is allowed by the parent
       directory ACL:
           allow delete
       else if ACE4_DELETE_CHILD is denied by the
       parent directory ACL:
           deny delete
       else if ACE4_ADD_FILE is allowed by the parent directory ACL:
           if MODE4_SVTX is set for the parent directory:
               if the principal owns the parent directory OR
                   the principal owns the target object OR
                   ACE4_WRITE_DATA is allowed by the target
                   object ACL:
                       allow delete
                   else:
                       deny delete
           else:
               allow delete
       else:
           deny delete

1.2.1.4.  ACE flag

   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

Shepler, et al.          Expires January 2, 2007               [Page 12]

Internet-Draft            NFSv4 Minor Version 1                July 2006

   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.

1.2.1.4.1.  Discussion of Flag Bits

   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
<comment>
This goes back to the algorithms which are now optional.  Can we find a different way to describe this?
</comment>
      Can be placed on a directory.  Normally when a new directory is
      created and an ACE exists on the parent directory which is marked
      ACE4_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
      The ACE4_SUCCESSFUL_ACCESS_ACE_FLAG (SUCCESS) and
      ACE4_FAILED_ACCESS_ACE_FLAG (FAILED) flag bits relate only to
      ACE4_SYSTEM_AUDIT_ACE_TYPE (AUDIT) and ACE4_SYSTEM_ALARM_ACE_TYPE
      (ALARM) ACE types.  If during the processing of the file's ACL,
      the server encounters an AUDIT or ALARM ACE that matches the
      principal attempting the OPEN, the server notes that fact, and the
      presence, if any, of the SUCCESS and FAILED flags encountered in
      the AUDIT or ALARM ACE.  Once the server completes the ACL
      processing, it then notes if the operation succeeded or failed.
      If the operation succeeded, and if the SUCCESS flag was set for a
      matching AUDIT or ALARM <comment> add "ACE" here </comment>, then the appropriate AUDIT or ALARM event
      occurs.  If the operation failed, and if the FAILED flag was set
      for the matching AUDIT or ALARM <comment> Add "ACE" here </comment>, then the appropriate AUDIT or
      ALARM event occurs.  <comment> Remove the word "Clearly" </comment> Clearly either or both of the SUCCESS or
      FAILED can be set, but if neither is set, the AUDIT or ALARM ACE
      is not useful.

Shepler, et al.          Expires January 2, 2007               [Page 13]

Internet-Draft            NFSv4 Minor Version 1                July 2006

      The previously described processing applies to that of the ACCESS
      operation as well, the difference being that "success" or
      "failure" does not mean whether ACCESS returns NFS4_OK or not.
      Success means whether ACCESS returns all requested and supported
      bits.  Failure means whether ACCESS failed to return a bit that
      was requested and supported.

   ACE4_IDENTIFIER_GROUP
      Indicates that the "who" refers to a GROUP as defined under UNIX
      or a GROUP ACCOUNT as defined under Windows.  Clients and servers
      must ignore the ACE4_IDENTIFIER_GROUP flag on ACEs with a who
      value equal to one of the special identifiers outlined in
      Section 1.2.1.5.

1.2.1.5.  ACE Who

<comment>
In general, be more consistent about whether the ACE4_ prefix is included.  Almost all cases it isn't needed.
</comment>

   The "who" field of an ACE is an identifier that specifies the
   principal or principals to whom the ACE applies.  It may refer to a
   user or a group, with the flag bit ACE4_IDENTIFIER_GROUP specifying
   which.

   There are several special identifiers 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, including the owner and owning group. |
   | 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.                    |
   +---------------+--------------------------------------------------+

                                  Table 2

   To avoid conflict, these special identifiers are distinguish by an
   appended "@" and should appear in the form "xxxx@" (note: no domain

Shepler, et al.          Expires January 2, 2007               [Page 14]

Internet-Draft            NFSv4 Minor Version 1                July 2006

   name after the "@").  For example: ANONYMOUS@.

1.2.1.5.1.  Discussion of EVERYONE@

   It is important to note that "EVERYONE@" is not equivalent to the
   UNIX "other" entity.  This is because, by definition, UNIX "other"
   does not include the owner or owning group of a file.  "EVERYONE@"
   means literally everyone, including the owner or owning group.

<comment>
Was the "Discussion of OWNER@ and GROUP@" section taken out for a reason or on accident?
</comment>

1.2.2.  mode Attribute

   The NFS version 4 mode attribute is based on the UNIX mode bits.  The
   following bits are defined:

           const MODE4_SUID = 0x800;  /* set user id on execution */
           const MODE4_SGID = 0x400;  /* set group id on execution */
           const MODE4_SVTX = 0x200;  /* save text even after use */
           const MODE4_RUSR = 0x100;  /* read permission: owner */
           const MODE4_WUSR = 0x080;  /* write permission: owner */
           const MODE4_XUSR = 0x040;  /* execute permission: owner */
           const MODE4_RGRP = 0x020;  /* read permission: group */
           const MODE4_WGRP = 0x010;  /* write permission: group */
           const MODE4_XGRP = 0x008;  /* execute permission: group */
           const MODE4_ROTH = 0x004;  /* read permission: other */
           const MODE4_WOTH = 0x002;  /* write permission: other */
           const MODE4_XOTH = 0x001;  /* execute permission: other */

   Bits MODE4_RUSR, MODE4_WUSR, and MODE4_XUSR apply to the principal
   identified in the owner attribute.  Bits MODE4_RGRP, MODE4_WGRP, and
   MODE4_XGRP apply to principals identified in the owner_group
   attribute but who are not identified in the owner attribute.  Bits
   MODE4_ROTH, MODE4_WOTH, MODE4_XOTH apply to any principal that does
   not match that in the owner attribute, and does not have a group
   matching that of the owner_group attribute.

   The remaining bits are not defined by this protocol.  A server MUST
   NOT return bits other than those defined above in a GETATTR or
   READDIR operation, and it MUST return NFS4ERR_INVAL if bits other
   than those defined above are set in a SETATTR, CREATE, or OPEN
   operation.

1.3.  Common Methods

   The requirements in this section will be referred to in future
   sections, especially Section 1.4.

Shepler, et al.          Expires January 2, 2007               [Page 15]

Internet-Draft            NFSv4 Minor Version 1                July 2006

1.3.1.  Interpreting an ACL

1.3.1.1.  Server Considerations
<comment>
Start out with the old text and add some MUSTs in there...
Don't make this section so lengthy.  The NFSv4 access checking algorithm is simple it should stay that way.  (Since it is capable of being explained in a couple of sentences, don't make it so long...)

Bruce has volunteered to write it...he will merge the old with the new...
</comment>

   Upon the server receiving a request to access an object in ways
   defined by the acemask4 values in Section 1.2.1.3, the server MUST
   meet the following requirements when interpreting the ACL on the
   object being accessed:

   1.   The ACEs in the ACL MUST be considered in order, with ACEs
        appearing earlier in the ACL taking precedence over those
        appearing later.

   2.   ACEs of type ACE4_SYSTEM_AUDIT_ACE_TYPE (AUDIT) and
        ACE4_SYSTEM_ALARM_ACE_TYPE (ALARM) do not affect the requester's
        access and MUST NOT be taken into account when determining the
        success or failure of the requested access.

   3.   ACEs of type ACE4_ACCESS_DENIED_ACE_TYPE (ALLOW) and
        ACE4_ACCESS_ALLOWED_ACE_TYPE (DENY) do affect the requester's
        access and MUST be taken into account when determining the
        success or failure of the requested access.

   4.   Only ACEs that have a who field that matches the requester will
        be considered when determining the success or failure of the
        requested access and when determining any possible audit and
        alarm events.

   5.   ALLOW and DENY type ACEs with the ACE4_INHERIT_ONLY_ACE flag set
        do not affect the requester's access to the current object and
        MUST NOT be taken into account when determining the success or
        failure of the requested access.

   6.   AUDIT and ALARM type ACEs with the ACE4_INHERIT_ONLY_ACE flag
        set MUST NOT be taken into account when determining the need for
        audit and alarm events.

   7.   The first ACE in the ACL that has a relevant access mask bit in
        an ACE4_ACCESS_ALLOWED_ACE_TYPE or ACE4_ACCESS_DENIED_ACE_TYPE
        ACE MUST determine whether the access defined by that access
        mask bit is allowed or denied, respectively.

        For example, a request made by the owner of the file to read an
        object with the following ACL will succeed:

       OWNER@:ACE4_READ_DATA::ALLOW
       OWNER@:ACE4_READ_DATA::DENY

Shepler, et al.          Expires January 2, 2007               [Page 16]

Internet-Draft            NFSv4 Minor Version 1                July 2006

        Conversely, a request made by the owner of the file to read an
        object with the following ACL will fail:

       OWNER@:ACE4_READ_DATA::DENY
       OWNER@:ACE4_READ_DATA::ALLOW

   8.   The allowed access MUST be determined by the accumulation of
        access mask bits allowed by the ACL.

        For example, given the following ACL, the owner of the file
        should be granted ACE4_READ_DATA and ACE4_WRITE_DATA
        permissions:

       OWNER@:ACE4_READ_DATA::ALLOW
       OWNER@:ACE4_WRITE_DATA::ALLOW

   9.   The denied access MUST be determined by the accumulation of all
        the access mask bits denied by the ACL.

        For example, given the following ACL, the owner of the file
        should be denied ACE4_READ_DATA and ACE4_WRITE_DATA permissions:

       OWNER@:ACE4_READ_DATA::DENY
       OWNER@:ACE4_READ_DATA::ALLOW
       OWNER@:ACE4_WRITE_DATA::DENY

   10.  A server SHOULD allow the request for access only if all
        requested access mask bits are in the list of allowed accesses
        retrieved when traversing the ACL.  Exceptions:

<comment>
Try NOT to make this look like an exhaustive list.  Instead of "Exceptions:" put "Examples:"
</comment>

        1.  If a file system is exported as read-only, the server MAY
            deny ACE4_WRITE_DATA even though an object's ACL therein
            grants it.

   11.  A server SHOULD deny the request for access if any of the
        requested access mask bits are in the list of denied accesses
        retrieved when traversing the ACL.  Exceptions:

<comment>
Try NOT to make this look like an exhaustive list.  Instead of "Exceptions:" put "Examples:"
</comment>

        1.  Server implementations MAY always grant ACE4_WRITE_ACL and
            ACE4_READ_ACL permissions in order to prevent the owner from
            getting into the situation where they can't ever modify the
            ACL.

        2.  All servers will allow a user the ability to read the data
            of the file when only the execute permission is granted
            (i.e.  If the ACL denies the user the ACE4_READ_DATA access
            and allows the user ACE4_EXECUTE, the server will allow the
            user to read the data of the file).

Shepler, et al.          Expires January 2, 2007               [Page 17]

Internet-Draft            NFSv4 Minor Version 1                July 2006

        3.  Many servers have the notion of owner-override in which the
            owner of the object is allowed to override accesses that are
            denied by the ACL.

   12.  A server SHOULD deny the request for access if any of the
        requested access mask bits have neither been allowed nor denied
        by the ALLOW and DENY ACES in the ACL.

1.3.1.2.  Client Considerations

   Clients SHOULD NOT do their own access checks based on their
   interpretation the ACL, but rather use the OPEN and ACCESS operations
   to do access checks.  This allows the client to act on the results of
   having the server determine whether or not access should be granted
   based on its interpretation of the ACL.

   Clients must be aware of situations in which an object's ACL will
   define a certain access even though the server will not enforce it.
   In general, but especially in these situations, the client needs to
   do its part in the enforcement of access as defined by the ACL.  To
   do this, the client MAY issue the appropriate ACCESS operation prior
   to servicing the request of the user or application in order to
   determine whether the user or application should be granted the
   access requested.  For examples in which the ACL may define accesses
   that the server doesn't enforce see Paragraph 11.2 and
   Paragraph 11.3.

1.3.2.  Computing a Mode Attribute from an ACL

   The following method can be used to calculate the nine most low-order
   bits of a mode attribute, based upon an ACL.

<comment>
Andreas commented that it is unclear that EVERYONE@ only affects the mode if they are in a certain order (e.g if EVERYONE@ is after a GROUP@ deny/allow pair)
</comment>

   1.  To determine MODE4_ROTH, MODE4_WOTH, and MODE4_XOTH:

       1.  If the special identifier EVERYONE@ is granted
           ACE4_READ_DATA, then the bit MODE4_ROTH SHOULD be set.
           Otherwise, MODE4_ROTH SHOULD NOT be set.

       2.  If the special identifier EVERYONE@ is granted
           ACE4_WRITE_DATA or ACE4_APPEND_DATA, then the bit MODE4_WOTH
           SHOULD be set.  Otherwise, MODE4_WOTH SHOULD NOT be set.

       3.  If the special identifier EVERYONE@ is granted ACE4_EXECUTE,
           then the bit MODE4_XOTH SHOULD be set.  Otherwise, MODE4_XOTH
           SHOULD NOT be set.

Shepler, et al.          Expires January 2, 2007               [Page 18]

Internet-Draft            NFSv4 Minor Version 1                July 2006

   2.  To determine MODE4_RGRP, MODE4_WGRP, and MODE4_XGRP, note that
       the EVERYONE@ special identifier SHOULD be taken into account.
       In other words, when determining if the GROUP@ special identifier
       is granted a permission, ACEs with the identifier EVERYONE@
       should take effect as usual.

       1.  If the special identifier GROUP@ is granted ACE4_READ_DATA,
           then the bit MODE4_RGRP SHOULD be set.  Otherwise, MODE4_RGRP
           SHOULD NOT be set.

       2.  If the special identifier GROUP@ is granted ACE4_WRITE_DATA
           or ACE4_APPEND_DATA, then the bit MODE4_WGRP SHOULD be set.
           Otherwise, MODE4_WGRP SHOULD NOT be set.

       3.  If the special identifier GROUP@ is granted ACE4_EXECUTE,
           then the bit MODE4_XGRP SHOULD be set.  Otherwise, MODE4_XGRP
           SHOULD NOT be set.

   3.  To determine MODE4_RUSR, MODE4_WUSR, and MODE4_XUSR, note that
       the EVERYONE@ special identifier SHOULD be taken into account.
       In other words, when determining if the OWNER@ special identifier
       is granted a permission, ACEs with the identifier EVERYONE@
       should take effect as usual.

       1.  If the special identifier OWNER@ is granted ACE4_READ_DATA,
           then the bit MODE4_RUSR SHOULD be set.  Otherwise, MODE4_RUSR
           SHOULD NOT be set.

       2.  If the special identifier OWNER@ is granted ACE4_WRITE_DATA
           or ACE4_APPEND_DATA, then the bit MODE4_WUSR SHOULD be set.
           Otherwise, MODE4_WUSR SHOULD NOT be set.

       3.  If the special identifier OWNER@ is granted ACE4_EXECUTE,
           then the bit MODE4_XUSR SHOULD be set.  Otherwise, MODE4_XUSR
           SHOULD NOT be set.

1.3.2.1.  Discussion

   The nine low-order mode bits correspond to ACE4_READ_DATA,
   ACE4_WRITE_DATA/ACE4_APPEND_DATA, and ACE4_EXECUTE for OWNER@,
   GROUP@, and EVERYONE@.  On some implementations, mode bits may
   represent a superset of these permissions, e.g. if a specific user is
   granted WRITE_DATA, then MODE4_WGRP will be set, even though the
   file's owner_group is not granted WRITE_DATA.

   Server implementations are discouraged from doing this, as experience
   has shown that this is confusing and annoying to end users.  The
   specifications above also discourage this practice to enforce the

Shepler, et al.          Expires January 2, 2007               [Page 19]

Internet-Draft            NFSv4 Minor Version 1                July 2006

   semantic that setting the mode attribute effectively specifies read,
   write, and execute for owner, group, and other.

<comment>
Either leave the following sentence out or reverse (i.e. change this to be that the client implementations SHOULD NOT use the ACL to compute this interpretation of the mode to give to the end user.
</comment>

   If required, client implementations may choose to retrieve an ACL
   attribute along with or in addition to the mode, and use the ACL to
   compute this interpretation of the mode to give to the end user.

1.4.  Requirements

   The server that supports both mode and ACL must take care to
   synchronize the MODE4_*USR, MODE4_*GRP, and MODE4_*OTH bits with the
   ACEs which have respective who fields of "OWNER@", "GROUP@", and
   "EVERYONE@" so that the client can see semantically equivalent access
   permissions exist whether the client asks for owner, owner_group and
   mode attributes, or for just the ACL.

<comment>
This should cover READ_ACL, etc.
</comment>

   In this section, much is made of the methods in Section 1.3.2.  Many
   requirements refer to this section.  But note that the methods have
   behaviors specified with "SHOULD".  This is intentional, to avoid
   invalidating existing implementations that compute the mode according
   to the withdrawn POSIX ACL draft (1003.1e draft 17), rather than by
   actual permissions on owner, group, and other.

1.4.1.  Setting the mode and/or ACL Attributes

1.4.1.1.  Setting mode and not ACL

   When setting a mode attribute and not an ACL attribute, the mode
   attribute MUST be set as given.  The ACL attribute MUST be modified
   such that the mode computed via the method in Section 1.3.2 yields
   the low-order nine bits of the newly set mode attribute.  The ACL
   SHOULD also be modified such that:

   1.  If MODE4_RGRP is not set, entities explicitly listed in the ACL
       other than the file owner and special identifiers SHOULD NOT be
       granted ACE4_READ_DATA.

<comment>
Need to make sure that the above is clear that it excludes OWNER@ and EVERYONE@, but leaves all others.
</comment>

   2.  If MODE4_WGRP is not set, entities explicitly listed in the ACL
       other than the file owner and special identifiers SHOULD NOT be
       granted ACE4_WRITE_DATA or ACE4_APPEND_DATA.

   3.  If MODE4_XGRP is not set, entities explicitly listed in the ACL
       other than the file owner and special identifiers SHOULD NOT be
       granted ACE4_EXECUTE.

   Access mask bits other those listed above, appearing in ALLOW ACEs,
   MAY also be disabled.

<comment>

Should we change the above MAY to SHOULD?
Need to do more research before changing to this.  What are the drawbacks, etc?  Need to have a longer discussion of security issues, POSIX issues, etc.

Options:
Could talk about more specifics (chmod vs. inherit time)?
</comment>

Shepler, et al.          Expires January 2, 2007               [Page 20]

Internet-Draft            NFSv4 Minor Version 1                July 2006

   Note that ACEs with the flag ACE4_INHERIT_ONLY_ACE set do not affect
   the permissions of the ACL itself, nor do ACEs of the type AUDIT and
   ALARM.  As such, it is desirable to leave these ACEs unmodified when
   modifying the ACL attribute.

   Also note that the requirement may be met by discarding the ACL, in
   favor of an ACL that represents the mode and only the mode.  This is
   permitted, but it is preferable for a server to preserve as much of
   the ACL as possible without violating the above requirements.
   Discarding the ACL makes it effectively impossible for a file created
   with a mode attribute to inherit an ACL (see Section 1.4.3).

1.4.1.2.  Setting ACL and not mode

   When setting an ACL attribute and not a mode attribute, the ACL
   attribute SHOULD be set as given.  The nine low-order bits of the
   mode attribute MUST be modified to match the result of the method
   Section 1.3.2.  The three high-order bits of the mode SHOULD remain
   unchanged.

1.4.1.3.  Setting both ACL and mode

   When setting both the mode and the ACL attribute in the same
   operation, the attributes MUST be applied in this order: mode, then
   ACL.  The mode attribute is set as given, then the ACL attribute is
   set as given, possibly changing the final mode, as described above in
   Section 1.4.1.2.

1.4.2.  Retrieving the mode and/or ACL Attributes

   This section applies only to servers that support both the mode and
   the ACL attribute.

   Some server implementations may have a concept of "objects without
   ACLs", meaning that all permissions are granted and denied according
   to the mode attribute, and that no ACL attribute is stored for that
   object.  If an ACL attribute is requested of such a server, the
   server SHOULD return an ACL that does not conflict with the mode;
   that is to say, the ACL returned SHOULD represent the nine low-order
   bits of the mode attribute as described in Section 1.3.2.

   For other server implementations, the ACL attribute is always present
   for every object.  Such servers SHOULD store at least the three high-
   order bits of the mode attribute (MODE4_SUID, MODE4_SGID,
   MODE4_SVTX).  The server SHOULD return a mode attribute if one is
   requested, and the low-order nine bits of the mode MUST match the
   result of applying the method in Section 1.3.2 to the ACL attribute.

Shepler, et al.          Expires January 2, 2007               [Page 21]

Internet-Draft            NFSv4 Minor Version 1                July 2006

1.4.3.  Creating New Objects

   If a server supports the ACL attribute, it may use the ACL attribute
   on the parent directory to compute an initial ACL attribute for a
   newly created object.  This will be referred to as the inherited ACL
   within this section.  The act of adding one or more ACEs to the
   inherited ACL that are based upon ACEs in the parent directory's ACL
   will be referred to as inheriting an ACE within this section.

   Implementors should standardize on what the behavior of CREATE and
   OPEN must be depending on the presence or absence of the mode and ACL
   attributes.

   1.  If just mode is given:

       In this case, inheritance SHOULD take place, but the mode MUST be
       applied to the inherited ACL as described in Section 1.4.1.1,
       thereby modifying the ACL.

   2.  If just ACL is given:

       In this case, inheritance SHOULD NOT take place, and the ACL as
       defined in the CREATE or OPEN will be set without modification,
       and the mode modified as in Section 1.4.1.2

<comment>
Before specifying the above make sure this is what Windows does...
This would basically only be done by Windows clients, therefore, we should make sure that this is relevant to them.
</comment>

   3.  If both mode and ACL are given:

       In this case, inheritance SHOULD NOT take place, and both
       attributes will be set as described in Section 1.4.1.3.

   4.  If neither mode nor ACL are given:

       In the case where an object is being created without any initial
       attributes at all, e.g. an OPEN operation with an opentype4 of
       OPEN4_CREATE and a createmode4 of EXCLUSIVE4, inheritance SHOULD
       NOT take place.  Instead, the server SHOULD set permissions to
       deny all access to the newly created object.  It is expected that
       the appropriate client will set the desired attributes in a
       subsequent SETATTR operation, and the server SHOULD allow that
       operation to succeed, regardless of what permissions the object
       is created with.  For example, an empty ACL denies all
       permissions, but the server should allow the owner's SETATTR to
       succeed even though WRITE_ACL is implicitly denied.

       In other cases, inheritance SHOULD take place, and no
       modifications to the ACL will happen.  The mode attribute, if
       supported, MUST be as computed in Section 1.3.2, with the three
       high-order bits clear <comment> Need to spell out what the "high-order bits" are here! </comment>.  It is worth noting that if no inheritable

Shepler, et al.          Expires January 2, 2007               [Page 22]

Internet-Draft            NFSv4 Minor Version 1                July 2006

       ACEs exist on the parent directory, the file will be created with
       an empty ACL, thus granting no access.

1.4.3.1.  The Inherited ACL

   If the object being created is not a directory, the inherited ACL
   SHOULD NOT inherit ACEs from the parent directory ACL unless the
   ACE4_FILE_INHERIT_FLAG is set.

   If the object being created is a directory, the inherited ACL SHOULD
   inherit ACEs from the parent directory that apply only to non-
   directories, i.e.  ACEs where the ACE4_FILE_INHERIT_ACE flag is set,
   but the ACE4_DIRECTORY_INHERIT_ACE is clear.  Such ACEs MUST have the
   ACE4_INHERIT_ONLY_ACE flag set, to prevent them from affecting the
   newly created directory.

<comment>
Remove the following paragraph...it is weird
</comment>

   A server MAY create a second copy of inheritable ACEs, with the
   ACE4_INHERIT_ONLY_ACE flag set.  One reason to do this is to preserve
   the original inheritable ACEs in case the object's ACL attribute is
   changed in the future.

   When a newly created object is created with attributes, and those
   attributes contain an ACL attribute and/or a mode attribute, the
   server MUST apply those attributes to the newly created object, as
   described in Section 1.4.1.

2.  Security Considerations

3.  ACL Algorithm Examples

   The following appendix is to be used as an informative source and it
   provides examples of how the requirements documented in Section 1 may
   be met.  The algorithms documented herein are in no way an indication
   of what is required for an implementation.  They are purely a
   mechanism for which to help implementors understand, more clearly,
   how the requirements could be met.  The algorithms documented have
   been implemented in the Solaris Operating System and are currently
   shipping in Solaris 10 Update 2.

<comment>
Remove the following text from the above paragraph:
The algorithms documented have been implemented in the Solaris Operating System and are currently shipping in Solaris 10 Update 2.
</comment>

3.1.  Recomputing mode upon SETATTR of ACL

   The following explains one implementation approach to computing the
   mode based on the ACL.  The goal of the following algorithm is to
   meet the requirements listed in Section 1.3.2.

   The general algorithm to assign a new mode attribute to an object

Shepler, et al.          Expires January 2, 2007               [Page 23]

Internet-Draft            NFSv4 Minor Version 1                July 2006

   based on a new ACL being set is:

   1.  Walk through the ACEs in order, looking for ACEs with a "who"
       value of OWNER@, GROUP@, or EVERYONE@.

   2.  It is understood that ACEs with a "who" value of OWNER@ affect
       the *USR bits of the mode, GROUP@ affect *GRP bits, and EVERYONE@
       affect *USR, *GRP, and *OTH bits.

   3.  If such an ACE specifies ALLOW or DENY for ACE4_READ_DATA,
       ACE4_WRITE_DATA, or ACE4_EXECUTE, and the mode bits affected have
       not been determined yet, set them to one (if ALLOW) or zero (if
       DENY).

   4.  Upon completion, any mode bits as yet undetermined have a value
       of zero.

   This pseudocode more precisely describes the algorithm:

         /* octal constants for the mode bits */

         RUSR = 0400
         WUSR = 0200
         XUSR = 0100
         RGRP = 0040
         WGRP = 0020
         XGRP = 0010
         ROTH = 0004
         WOTH = 0002
         XOTH = 0001

        /*
         * old_mode represents the previous value
         * of the mode of the object.
         */

         mode_t mode = 0, seen = 0;
         for each ACE a {
             if a.type is ALLOW or DENY and
             ACE4_INHERIT_ONLY_ACE is not set in a.flags {
                 if a.who is OWNER@ {
                     if ((a.mask & ACE4_READ_DATA) &&
                         (! (seen & RUSR))) {
                             seen |= RUSR;
                             if a.type is ALLOW {
                                 mode |= RUSR;
                             }
                     }

Shepler, et al.          Expires January 2, 2007               [Page 24]

Internet-Draft            NFSv4 Minor Version 1                July 2006

                     if ((a.mask & ACE4_WRITE_DATA) &&
                         (! (seen & WUSR))) {
                             seen |= WUSR;
                             if a.type is ALLOW {
                                 mode |= WUSR;
                             }
                     }
                     if ((a.mask & ACE4_EXECUTE) &&
                         (! (seen & XUSR))) {
                             seen |= XUSR;
                             if a.type is ALLOW {
                                 mode |= XUSR;
                             }
                     }
                 } else if a.who is GROUP@ {
                     if ((a.mask & ACE4_READ_DATA) &&
                         (! (seen & RGRP))) {
                             seen |= RGRP;
                             if a.type is ALLOW {
                                 mode |= RGRP;
                             }
                     }
                     if ((a.mask & ACE4_WRITE_DATA) &&
                         (! (seen & WGRP))) {
                             seen |= WGRP;
                             if a.type is ALLOW {
                                 mode |= WGRP;
                             }
                     }
                     if ((a.mask & ACE4_EXECUTE) &&
                         (! (seen & XGRP))) {
                             seen |= XGRP;
                             if a.type is ALLOW {
                                 mode |= XGRP;
                             }
                     }
                 } else if a.who is EVERYONE@ {
                     if (a.mask & ACE4_READ_DATA) {
                         if ! (seen & RUSR) {
                             seen |= RUSR;
                             if a.type is ALLOW {
                                 mode |= RUSR;
                             }
                         }
                         if ! (seen & RGRP) {
                             seen |= RGRP;
                             if a.type is ALLOW {
                                 mode |= RGRP;

Shepler, et al.          Expires January 2, 2007               [Page 25]

Internet-Draft            NFSv4 Minor Version 1                July 2006

                             }
                         }
                         if ! (seen & ROTH) {
                             seen |= ROTH;
                             if a.type is ALLOW {
                                 mode |= ROTH;
                             }
                         }
                     }
                     if (a.mask & ACE4_WRITE_DATA) {
                         if ! (seen & WUSR) {
                             seen |= WUSR;
                             if a.type is ALLOW {
                                 mode |= WUSR;
                             }
                         }
                         if ! (seen & WGRP) {
                             seen |= WGRP;
                             if a.type is ALLOW {
                                 mode |= WGRP;
                             }
                         }
                         if ! (seen & WOTH) {
                             seen |= WOTH;
                             if a.type is ALLOW {
                                 mode |= WOTH;
                             }
                         }
                     }
                     if (a.mask & ACE4_EXECUTE) {
                         if ! (seen & XUSR) {
                             seen |= XUSR;
                             if a.type is ALLOW {
                                 mode |= XUSR;
                             }
                         }
                         if ! (seen & XGRP) {
                             seen |= XGRP;
                             if a.type is ALLOW {
                                 mode |= XGRP;
                             }
                         }
                         if ! (seen & XOTH) {
                             seen |= XOTH;
                             if a.type is ALLOW {
                                 mode |= XOTH;
                             }
                         }

Shepler, et al.          Expires January 2, 2007               [Page 26]

Internet-Draft            NFSv4 Minor Version 1                July 2006

                     }
                 }
             }
         }
         return mode | (old_mode & (SUID | SGID | SVTX))

3.2.  Computing the Inherited ACL

   The following explains one implementation approach to compute an
   inherited ACL.  The algorithm meets the requirements listed in
   Section 1.4.3.1.

   1.  Examine the ACL on the directory of the current filehandle.  Form
       a concatenation of the ACEs on which either ACE4_FILE_INHERIT_ACE
       or ACE4_DIRECTORY_INHERIT_ACE is set.  Call this ACL "N".

   2.  Create an empty ACL, and call it "O".

   3.  If the object being created is not a directory, delete any ACEs
       from N on which ACE4_FILE_INHERIT_ACE is not set.

   4.  Process the ACEs of N, in order.  For each ACE:

       1.  If ACE4_NO_PROPAGATE_INHERIT_ACE is not set, append an ACE to
           O, with ACE4_INHERIT_ONLY_ACE set, but otherwise identical to
           the ACE in N. Note that ACE4_INHERIT_ONLY_ACE may have
           already been set in the original ACE in N.

       2.  If the object being created is a directory, and
           ACE4_DIRECTORY_INHERIT_ACE is not set, delete the ACE from N.

       3.  Otherwise, if the condition in Paragraph 4.2 above was not
           met, clear these flags from the ACE in N:

              ACE4_FILE_INHERIT_ACE

              ACE4_DIRECTORY_INHERIT_ACE

              ACE4_NO_PROPAGATE_INHERIT_ACE

              ACE4_INHERIT_ONLY_ACE

   5.  The inherited ACL is formed from all of the ACEs of N and O. The
       ACEs from N must appear in the same order as they were in N, and
       the ACEs of O must appear in the same order as they were in O.

Shepler, et al.          Expires January 2, 2007               [Page 27]

Internet-Draft            NFSv4 Minor Version 1                July 2006

3.2.1.  Discussion

   The intent of Paragraph 1 is to create a prototype ACL, made of the
   inheritable ACEs from the parent directory.

   The intent of Paragraph 2 is to create a supplemental ACL, made of
   ACEs that do not affect the permissions granted or denied, nor the
   events audited or alarmed, by the new ACL.  Instead, the ACEs in O
   preserve the original intended inheritable ACEs if and when the ACEs
   of N are modified or discarded.

   The intent of Paragraph 3 is to prevent permissions, audits and
   alarms intended for directories to be applied to non-directories.

   The intent of Paragraph 4.1 is to build the ACL O, based upon ACEs
   that will be inherited in the future.

   The intent of Paragraph 4.2 is to prevent permissions, audits and
   alarms intended for non-directories to be applied to directories.

   The intent of Paragraph 4.3 is to finish the ACL N, by turning off
   inheritance-related flags.  Inheritance is not needed in the ACEs of
   N, since this is covered by the ACEs in O.

   The intent of Paragraph 5 is to form the final version of the
   inherited ACL.  The ACEs of each of the sub-ACLs, N and O, must be
   kept in order, but there are many ways to produce the final ACL.  An
   easy example is to concatenate the ACEs of N with the ACEs of O;
   another way is to interleave ACEs from N and O, so long as their
   final orders are preserved.

3.3.  Applying a Mode to an Existing ACL

   When a mode is applied to an object, e.g. via SETATTR or CREATE/OPEN,
   the ACL must be modified to accommodate the mode.

   1.  The ACL is traversed, one ACE at a time.  For each ACE:

       1.  If the type of the ACE is neither ALLOW nor DENY, the ACE is
           left unchanged.  Continue to the next ACE.

       2.  If the ACE4_INHERIT_ONLY_ACE flag is set on the ACE, it is
           left unchanged.  Continue to the next ACE.

       3.  If either or both of ACE4_FILE_INHERIT_ACE or
           ACE4_DIRECTORY_INHERIT_ACE are set:

Shepler, et al.          Expires January 2, 2007               [Page 28]

Internet-Draft            NFSv4 Minor Version 1                July 2006

           1.  A copy of the ACE is made, and placed in the ACL
               immediately following the current ACE.

           2.  In the first ACE, the flag ACE4_INHERIT_ONLY_ACE is set.

           3.  In the second ACE, the following flags are cleared:

                  ACE4_FILE_INHERIT_ACE

                  ACE4_DIRECTORY_INHERIT_ACE

                  ACE4_NO_PROPAGATE_INHERIT_ACE

           The algorithm continues on with the second ACE.

       4.  If the "who" field is one of the following:

              OWNER@

              GROUP@

              EVERYONE@

           then the following mask bits are cleared:

              ACE4_READ_DATA / ACE4_LIST_DIRECTORY

              ACE4_WRITE_DATA / ACE4_ADD_FILE

              ACE4_APPEND_DATA / ACE4_ADD_SUBDIRECTORY

              ACE4_EXECUTE

           At this point, we proceed to the next ACE.

       5.  Otherwise, if the "who" field did not match one of OWNER@,
           GROUP@, or EVERYONE@, the following steps SHOULD be
           performed.

           1.  If the type of the ACE is ALLOW, we check the preceding
               ACE (if any).  If it does not meet all of the following
               criteria:

               1.  The type field is DENY.

               2.  The who field is the same as the current ACE.

Shepler, et al.          Expires January 2, 2007               [Page 29]

Internet-Draft            NFSv4 Minor Version 1                July 2006

               3.  The flag bit ACE4_IDENTIFIER_GROUP is the same as it
                   is in the current ACE, and no other flag bits are
                   set.

               4.  The mask bits are a subset of the mask bits of the
                   current ACE, and are also a subset of the following:

                      ACE4_READ_DATA / ACE4_LIST_DIRECTORY

                      ACE4_WRITE_DATA / ACE4_ADD_FILE

                      ACE4_APPEND_DATA / ACE4_ADD_SUBDIRECTORY

                      ACE4_EXECUTE

               then an ACE of type DENY, with a who equal to the current
               ACE, flag bits equal to (<current-ACE-flags> &
               ACE4_IDENTIFIER_GROUP), and no mask bits, is prepended.

           2.  The following modifications are made to the prepended
               ACE.  The intent is to mask the following ACE to disallow
               ACE4_READ_DATA, ACE4_WRITE_DATA, ACE4_APPEND_DATA, or
               ACE4_EXECUTE, based upon the group permissions of the new
               mode.  As a special case, if the ACE matches the current
               owner of the file, the owner bits are used, rather than
               the group bits.  This is reflected in the algorithm
               below.

Shepler, et al.          Expires January 2, 2007               [Page 30]

Internet-Draft            NFSv4 Minor Version 1                July 2006

        Let there be three bits defined:

        #define READ    04
        #define WRITE   02
        #define EXEC    01

        Let "amode" be the new mode, right-shifted three
        bits, in order to have the group permission bits
        placed in the three low order bits of amode,
        i.e. amode = mode >> 3

        If ACE4_IDENTIFIER_GROUP is not set in the flags,
        and the "who" field of the ACE matches the owner
        of the file, we shift amode three more bits, in
        order to have the owner permission bits placed in
        the three low order bits of amode:

        amode = amode >> 3

        amode is now used as follows:

        If ACE4_READ_DATA is set on the current ACE:
                   If READ is set on amode:
                       ACE4_READ_DATA is cleared on the prepended ACE
                   else:
                       ACE4_READ_DATA is set on the prepended ACE

            If ACE4_WRITE_DATA is set on the current ACE:
                   If WRITE is set on amode:
                       ACE4_WRITE_DATA is cleared on the prepended ACE
                   else:
                       ACE4_WRITE_DATA is set on the prepended ACE
            If ACE4_APPEND_DATA is set on the current ACE:
                   If WRITE is set on amode:
                       ACE4_APPEND_DATA is cleared on the
                       prepended ACE
                   else:
                       ACE4_APPEND_DATA is set on the prepended ACE

            If ACE4_EXECUTE is set on the current ACE:
                   If EXEC is set on amode:
                       ACE4_EXECUTE is cleared on the prepended ACE
                   else:
                       ACE4_EXECUTE is set on the prepended ACE

           3.  To conform with POSIX, and prevent cases where the owner
               of the file is given permissions via an explicit group,
               we implement the following step.

Shepler, et al.          Expires January 2, 2007               [Page 31]

Internet-Draft            NFSv4 Minor Version 1                July 2006

       If ACE4_IDENTIFIER_GROUP is set in the flags field of
       the ALLOW ACE:
           Let "mode" be the mode that we are chmoding to:
               extramode = (mode >> 3) & 07
               ownermode = mode >> 6
               extramode &= ~ownermode
           If extramode is not zero:
               If extramode & READ:
                   Clear ACE4_READ_DATA in both the
                   prepended DENY ACE and the ALLOW ACE
               If extramode & WRITE:
                   Clear ACE4_WRITE_DATA and ACE_APPEND_DATA
                   in both the prepended DENY ACE and the
                   ALLOW ACE
           If extramode & EXEC:
                   Clear ACE4_EXECUTE in both the prepended
                   DENY ACE and the ALLOW ACE

   2.  If there are at least six ACEs, the final six ACEs are examined.
       If they are not equal to the following ACEs:

       A1) OWNER@:::DENY
       A2) OWNER@:ACE4_WRITE_ACL/ACE4_WRITE_OWNER/
           ACE4_WRITE_ATTRIBUTES/ACE4_WRITE_NAMED_ATTRIBUTES::ALLOW
       A3) GROUP@::ACE4_IDENTIFIER_GROUP:DENY
       A4) GROUP@::ACE4_IDENTIFIER_GROUP:ALLOW
       A5) EVERYONE@:ACE4_WRITE_ACL/ACE4_WRITE_OWNER/
           ACE4_WRITE_ATTRIBUTES/ACE4_WRITE_NAMED_ATTRIBUTES::DENY
       A6) EVERYONE@:ACE4_READ_ACL/ACE4_READ_ATTRIBUTES/
           ACE4_READ_NAMED_ATTRIBUTES/ACE4_SYNCHRONIZE::ALLOW

       Then six ACEs matching the above are appended.

   3.  The final six ACEs are adjusted according to the incoming mode.

Shepler, et al.          Expires January 2, 2007               [Page 32]

Internet-Draft            NFSv4 Minor Version 1                July 2006

       /* octal constants for the mode bits */

       RUSR = 0400
       WUSR = 0200
       XUSR = 0100
       RGRP = 0040
       WGRP = 0020
       XGRP = 0010
       ROTH = 0004
       WOTH = 0002
       XOTH = 0001

       If RUSR is set: set ACE4_READ_DATA in A2
       else: set ACE4_READ_DATA in A1
       If WUSR is set: set ACE4_WRITE_DATA and ACE4_APPEND_DATA in A2
       else: set ACE4_WRITE_DATA and ACE4_APPEND_DATA in A1
       If XUSR is set: set ACE4_EXECUTE in A2
       else: set ACE4_EXECUTE in A1
       If RGRP is set: set ACE4_READ_DATA in A4
       else: set ACE4_READ_DATA in A3
       If WGRP is set: set ACE4_WRITE_DATA and ACE4_APPEND_DATA in A4
       else: set ACE4_WRITE_DATA and ACE4_APPEND_DATA in A3
       If XGRP is set: set ACE4_EXECUTE in A4
       else: set ACE4_EXECUTE in A3
       If ROTH is set: set ACE4_READ_DATA in A6
       else: set ACE4_READ_DATA in A5
       If WOTH is set: set ACE4_WRITE_DATA and ACE4_APPEND_DATA in A6
       else: set ACE4_WRITE_DATA and ACE4_APPEND_DATA in A5
       If XOTH is set: set ACE4_EXECUTE in A6
       else: set ACE4_EXECUTE in A5

4.  References

4.1.  Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", March 1997.

   [2]  International Organization for Standardization, "Information
        Technology - Universal Multiple-octet coded Character Set (UCS)
        - Part 1: Architecture and Basic Multilingual Plane",
        ISO Standard 10646-1, May 1993.

   [3]  Srinivasan, R., "RPC: Remote Procedure Call Protocol
        Specification Version 2", RFC 1831, August 1995.

   [4]  Hinden, R. and S. Deering, "IP Version 6 Addressing

Shepler, et al.          Expires January 2, 2007               [Page 33]

Internet-Draft            NFSv4 Minor Version 1                July 2006

        Architecture", RFC 1884, December 1995.

   [5]  Alvestrand, H., "IETF Policy on Character Sets and Languages",
        BCP 18, RFC 2277, January 1998.

   [6]  Linn, J., "Generic Security Service Application Program
        Interface Version 2, Update 1", RFC 2743, January 2000.

   [7]  Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame,
        C., Eisler, M., and D. Noveck, "Network File System (NFS)
        version 4 Protocol", RFC 3530, April 2003.

   [8]  Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms
        and Identifiers for RSA Cryptography for use in the Internet
        X.509 Public Key Infrastructure Certificate and Certificate
        Revocation List (CRL) Profile", RFC 4055, June 2005.

   [9]  Eisler, M., "XDR: External Data Representation Standard",
        STD 67, RFC 4506, May 2006.

4.2.  Informative References

   [10]  Srinivasan, R., "Binding Protocols for ONC RPC Version 2",
         RFC 1833, August 1995.

   [11]  Black, D., "pNFS Block/Volume Layout", July 2005, <ftp://
         www.ietf.org/internet-drafts/draft-black-pnfs-block-01.txt>.

   [12]  Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., and E.
         Zeidner, "Internet Small Computer Systems Interface (iSCSI)",
         RFC 3720, April 2004.

   [13]  Snively, R., "Fibre Channel Protocol for SCSI, 2nd Version
         (FCP-2)", ANSI/INCITS 350-2003, Oct 2003.

   [14]  Weber, R., "Object-Based Storage Device Commands (OSD)", ANSI/
         INCITS 400-2004, July 2004,
         <http://www.t10.org/ftp/t10/drafts/osd/osd-r10.pdf>.

   [15]  Zelenka, J., Welch, B., and B. Halevy, "Object-based pNFS
         Operations", July 2005, <ftp://www.ietf.org/internet-drafts/
         draft-zelenka-pnfs-obj-01.txt>.

Appendix A.  Acknowledgments

   The initial drafts for the SECINFO extensions were edited by Mike
   Eisler with contributions from Tom Talpey, Saadia Khan, and Jon

Shepler, et al.          Expires January 2, 2007               [Page 34]

Internet-Draft            NFSv4 Minor Version 1                July 2006

   Bauman.

   The initial drafts for the SESSIONS extensions were edited by Tom
   Talpey, Spencer Shepler, Jon Bauman with contributions from Charles
   Antonelli, Brent Callaghan, Mike Eisler, John Howard, Chet Juszczak,
   Trond Myklebust, Dave Noveck, John Scott, Mike stolarchuk and Mark
   Wittle.

   The initial drafts for the Directory Delegations support were
   contributed by Saadia Khan with input from Dave Noveck, Mike Eisler,
   Carl Burnett, Ted Anderson and Tom Talpey.

   The initial drafts for the ACL explanations were contributed by Sam
   Falkner and Lisa Week.

   The initial drafts for the parellel NFS support were edited by Brent
   Welch and Garth Goodson.  Additional authors for those documents were
   Benny Halevy, David Black, and Andy Adamson.  Additional input came
   from the informal group which contributed to the construction of the
   initial pNFS drafts; specific acknowledgement goes to Gary Grider,
   Peter Corbett, Dave Noveck, and Peter Honeyman.  The pNFS work was
   inspired by the NASD and OSD work done by Garth Gibson.  Gary Grider
   of the national labs (LANL) has also been a champion of high-
   performance parallel I/O.

Shepler, et al.          Expires January 2, 2007               [Page 35]

Internet-Draft            NFSv4 Minor Version 1                July 2006

Authors' Addresses

   Spencer Shepler
   Sun Microsystems, Inc.
   7808 Moonflower Drive
   Austin, TX  78750
   USA

   Phone: +1-512-349-9376
   Email: [email-masked]

   Mike Eisler
   Network Appliance, Inc.
   5765 Chase Point Circel
   Colorado Springs, CO  80919
   USA

   Phone: +1-719-4599-9026
   Email: [email-masked]

   David Noveck
   Sun Microsystems, Inc.
   1601 Trapelo Road, Suite 16
   Waltham, MA  02454
   USA

   Phone: +1-781-961-9291
   Email: [email-masked]

Shepler, et al.          Expires January 2, 2007               [Page 36]

Internet-Draft            NFSv4 Minor Version 1                July 2006

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Shepler, et al.          Expires January 2, 2007               [Page 37]

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 14 Aug 2006 16:53:25 -0500

> GROUP@ can and will change with a chown to a different group (chgrp command)

DENY ACEs are evil.  Group DENY ACEs all the more so.

I'd like to remind you of a discussion at the Pairs and Vancouver KITTEN
WG meetings about this.

We concluded then that group DENY ACEs are only effective when the
access evaluator (the server) necessarily knows about all of the
subject's group memberships, including all possible groups that might be
listed in DENY ACEs.

Making sure that a server can know about all such group memberships of a
given user is difficult, particularly in environments with multiple
domains.

We discussed Windows and Active Directory specifically.  It turns out
that Windows' UI does not allow one to create DENY ACEs for groups that
are not local to the server or its domain precisely because evaluating
group membership across an Active Directory forest is non-trivial.

Therefore I recommend that text be added RECOMMENDing care when creating
group DENY ACEs.

I also recommend that use of DENY ACEs be discouraged.

I might even recommend text REQUIREing the server to reject ACLs with
group DENY ACEs for non-local groups, but I think this is best left as a
UI issue for now.

Summary: DENY ACEs introduce order issues.  Group DENY ACEs add a
	 requirement that servers be able to know about all client
	 principals' possible group memberships where such groups can be
	 denied access.

Nico
--

---

From: "J. Bruce Fields" <[email-masked]>
Date: Mon, 14 Aug 2006 18:15:55 -0400

> subject's group memberships, including all possible groups that might be

Yep, good point.

--b.