Subject: [nfsv4] [PATCH 05/11] acls: permit silently turning off allow bits

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 27 Mar 2007 18:48:35 -0400

From: J. Bruce Fields <[email-masked]>

I think it may actually be preferable to turn off the allow bit in this
example.

Given that, the DENY example then seems redundant.
---
 nfsv41_middle_fileattributes_acls.xml |   10 ++++------
 1 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/nfsv41_middle_fileattributes_acls.xml b/nfsv41_middle_fileattributes_acls.xml
index 593154e..9dc13c1 100755
--- a/nfsv41_middle_fileattributes_acls.xml
+++ b/nfsv41_middle_fileattributes_acls.xml
@@ -508,13 +508,11 @@
                         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
+                        paragraph. If a client submits an ALLOW ACE where
                         ACE4_APPEND_DATA is set but ACE4_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 ACE4_APPEND_DATA and ACE4_WRITE_DATA
-                        are denied.
+                        (or vice versa), the server should either turn off
+                        ACE4_APPEND DATA or reject the request with
+                        NFS4ERR_ATTRNOTSUPP.
                     </t>
                 </section>
 
-- 
1.5.0.3.31.ge47c

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 27 Mar 2007 18:48:35 -0400

-- 
1.5.0.3.31.ge47c

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 27 Mar 2007 18:48:36 -0400

The pseudocode here allows unlinking any writeable file in a directory
with the sticky bit set.  That seems wrong.

Also I find the pseudocode a little wordy.  I think we can get across
essentially the same level of detail a little more efficiently.
---
 nfsv41_middle_fileattributes_acls.xml |   69 +++++++++++---------------------
 1 files changed, 24 insertions(+), 45 deletions(-)

diff --git a/nfsv41_middle_fileattributes_acls.xml b/nfsv41_middle_fileattributes_acls.xml
index 9dc13c1..fc67844 100755
--- a/nfsv41_middle_fileattributes_acls.xml
+++ b/nfsv41_middle_fileattributes_acls.xml
@@ -519,59 +519,38 @@
                 <section anchor="delete-delete_child" title="ACE4_DELETE vs. ACE4_DELETE_CHILD">
                     <t>
                         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.
+                        directory entry: ACE4_DELETE on the file or directory
+                        referred to (the "target"), and ACE4_DELETE_CHILD on
+                        the containing directory (the "parent").
                     </t>
-                    <t>           
-                        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.
+
+                    <t>
+                        Many systems also take the "sticky bit" (MODE4_SVTX)
+                        on a directory to allow unlink only to a user that
+                        owns either the target or the parent.
                     </t>
 
                     <t>
-                        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). </t>
+                        Servers SHOULD allow unlink if either ACE4_DELETE
+                        is permitted on the target, or ACE4_DELETE_CHILD is
+                   .ietf.org with esmtp (Exim 4.43) id 1HWKT9-0007VU-CW
	for [email-masked]; Tue, 27 Mar 2007 18:48:53 -0400
From: "J. Bruce Fields" <[email-masked]>
To: [email-masked]
Cc: 
Date: Tue, 27 Mar 2007 18:48:36 -0400
Subject: [nfsv4] [PATCH 06/11] acls: fix DELETE/DELETE_CHILD algorithm,
	rewrite for conciseness

The pseudocode here allows unlinking any writeable file in a directory
with the sticky bit set.  That seems wrong.

Also I find the pseudocode a little wordy.  I think we can get across
essentially the same level of detail a little more efficiently.
---
 nfsv41_middle_fileattributes_acls.xml |   69 +++++++++++---------------------
 1 files changed, 24 insertions(+), 45 deletions(-)

diff --git a/nfsv41_middle_fileattributes_acls.xml b/nfsv41_middle_fileattributes_acls.xml
index 9dc13c1..fc67844 100755
--- a/nfsv41_middle_fileattributes_acls.xml
+++ b/nfsv41_middle_fileattributes_acls.xml
@@ -519,59 +519,38 @@
                 <section anchor="delete-delete_child" title="ACE4_DELETE vs. ACE4_DELETE_CHILD">
                     <t>
                         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.
+                        directory entry: ACE4_DELETE on the file or directory
+                        referred to (the "target"), and ACE4_DELETE_CHILD on
+                        the containing directory (the "parent").
                     </t>
-                    <t>           
-                        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.
+
+                    <t>
+                        Many systems also take the "sticky bit" (MODE4_SVTX)
+                        on a directory to allow unlink only to a user that
+                        owns either the target or the parent.
                     </t>
 
                     <t>
-                        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). </t>
+                        Servers SHOULD allow unlink if either ACE4_DELETE
+                        is permitted on the target, or ACE4_DELETE_CHILD is
+                        permitted on the parent.
+                    </t>
 
                     <t>
-                        Server implementations SHOULD grant or deny permission
-                        to delete based on the following algorithm.
+                       If the ACLs in question have neither an explicit ALLOW
+                       nor an explicit DENY for either of the above, then
+                       the server SHOULD allow the removal if and only if
+                       the parent both has MODE4_SVTX set and permits
+                       ACE4_ADD_FILE, and the remover owns either the parent
+                       or the target.
+                    </t>
+
+                    <t>
+                        This allows servers to support something close to
+                        traditional unix-like semantics, with ACE4_ADD_FILE
+                        taking the place of the write bit.
                     </t>
 
-                    <figure>
-                        <artwork>
-    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
-                        </artwork>
-                    </figure>
                 </section>
             </section>
             <section anchor="aceflag" title="ACE flag">
-- 
1.5.0.3.31.ge47c

     permitted on the parent.
+                    </t>
 
                     <t>
-                        Server implementations SHOULD grant or deny permission
-                        to delete based on the following algorithm.
+                       If the ACLs in question have neither an explicit ALLOW
+                       nor an explicit DENY for either of the above, then
+                       the server SHOULD allow the removal if and only if
+                       the parent both has MODE4_SVTX set and permits
+                       ACE4_ADD_FILE, and the remover owns either the parent
+                       or the target.
+                    </t>
+
+                    <t>
+                        This allows servers to support something close to
+                        traditional unix-like semantics, with ACE4_ADD_FILE
+                        taking the place of the write bit.
                     </t>
 
-                    <figure>
-                        <artwork>
-    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
-                        </artwork>
-                    </figure>
                 </section>
             </section>
             <section anchor="aceflag" title="ACE flag">
-- 
1.5.0.3.31.ge47c

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 27 Mar 2007 18:48:33 -0400

We discussed this change before, and I believe it was agreed to but then
forgotten.

The existing language allows the server to "indicate that it supports
ACLs as long as it follows" certain guidelines, but without providing
any guidance as to what kind of guidelines are acceptable.

This has been taken to mean that the server may support an arbitrarily
restrictive and complex subset of the NFSv4 ACLs as long as some
guidelines are written down somewhere explaining this.

However, this is interpretation is probably not what was originally
intended, and in practice it causes interoperability problems.  So we
should encourage servers to accept the full ACL protocol to the extent
possible.
---
 nfsv41_middle_fileattributes_acls.xml |   10 ++++++----
 1 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/nfsv41_middle_fileattributes_acls.xml b/nfsv41_middle_fileattributes_acls.xml
index dcc6403..b93af93 100755
--- a/nfsv41_middle_fileattributes_acls.xml
+++ b/nfsv41_middle_fileattributes_acls.xml
@@ -142,10 +142,12 @@
                 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 ACL model.
+                as the NFS ACL model.  So that users can take advantage of this
+                more limited functionality, the server may support the acl
+                attribute by mapping between its ACL model and the NFS version
+                4 ACL model.  Such servers SHOULD nevertheless accept any
+                NFSv4 ACL, and ensure that the ACL they actually store or
+                enforce is at least as strict as the NFSv4 ACL that was set.
             </t>
             <t>
                 The situation is complicated by the fact that a server may
-- 
1.5.0.3.31.ge47c

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 27 Mar 2007 18:48:30 -0400

Apologies for the mailbomb; if some other way of doing this would be
more convenient, let me know.

The following is mainly cleanup of the ACL section, in the form of
patches against the draft -10 xml, partly as a response to a request for
review of the ACL section.

A couple other random comments:

The named attribute permissions model is a little vague.  For example,
if you already have a filehandle for the named attribute directory, do
you still need read_named_attr permission to read those attributes, or
will read permissions on the attributes themselves do the job?  (They
can have permissions, right?)  Given the possibile variation in
implementations, I'd rather just not decide--say "read_named_attr
controls permission to read the named attributes" and leave it at that.
But that makes stuff like the detailed list of operations affected kind
of a problem.

In the exclusive create case we're requiring the clients to perform ACL
inheritance themselves.  That requires clients to manipulate the
inherited ACL to take into account the create mode.  OK, arguably maybe
all such mode emulation should be done on the client side anyway, since
they're required to deal with the case of the (so far nonexistant)
server that doesn't support mode at all.  But this is kind of a can of
worms.  I intend to solve the problem by ensuring we always do masking
on the server side, but I don't know what other implementations will
do....  Maybe just not worry about that case.

--b.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 27 Mar 2007 18:48:39 -0400

Revise the third paragraph for clarity and conciseness.  Remove the
final paragraph, which seems redundant given the previous section.
---
 nfsv41_middle_fileattributes_acls.xml |   22 +++++++---------------
 1 files changed, 7 insertions(+), 15 deletions(-)

diff --git a/nfsv41_middle_fileattributes_acls.xml b/nfsv41_middle_fileattributes_acls.xml
index 7fc775e..29b831e 100755
--- a/nfsv41_middle_fileattributes_acls.xml
+++ b/nfsv41_middle_fileattributes_acls.xml
@@ -1272,24 +1272,16 @@
                     from being affected by ACEs meant for non-directories.
                 </t>
                 <t>
-                    When a new directory is created and it inherits ACEs
-                    from its parent, for each inheritable ACE which affects
-                    the directory's permissions, a server MAY create two ACEs
-                    on the directory being created; one effective and one
-                    which is only inheritable (i.e. has ACE4_INHERIT_ONLY_ACE
-                    flag set).  This gives the user and the server, in the
-                    cases which it must mask certain permissions upon
-                    creation, the ability to modify the effective permissions
+                    When a new directory is created, the server MAY split
+                    any inherited ACE which is both inheritable and effective
+                    (in other words, which has neither ACE4_INHERIT_ONLY_ACE
+                    nor ACE4_NO_PROPAGATE_INHERIT_ACE set), into two ACEs,
+                    one with no inheritance flags, and one with
+                    ACE4_INHERIT_ONLY_ACE set.  This makes it possible to
+                    later modify the effective permissions on the directory
                     without modifying the ACE which is to be inherited to the
                     new directory's children.
                 </t>
-                <t>
-                    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 <xref
-                    target="setattr" />.
-                </t>
             </section>
 	    
             <section title="Automatic Inheritance" anchor="auto_inherit">
-- 
1.5.0.3.31.ge47c

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 27 Mar 2007 18:48:40 -0400

I'm happy to accept a longer description where it helps the reader, but
other things being equal I'd prefer conciseness, and the redundancy here
seems like overkill.  Here's my attempt at a shorter description of the
same algorithm without pseudocode.
---
 nfsv41_middle_fileattributes_acls.xml |  104 +++++++++------------------------
 1 files changed, 28 insertions(+), 76 deletions(-)

diff --git a/nfsv41_middle_fileattributes_acls.xml b/nfsv41_middle_fileattributes_acls.xml
index 29b831e..27cf2e8 100755
--- a/nfsv41_middle_fileattributes_acls.xml
+++ b/nfsv41_middle_fileattributes_acls.xml
@@ -944,88 +944,40 @@
                 The following method can be used to calculate the MODE4_R*,
                 MODE4_W* and MODE4_X* bits of a mode attribute, based upon
                 an ACL.
-                
+            </t>
+
+            <t>
+                First, for each of the special identifiers ONWER@, GROUP@, and
+                EVERYONE@, evaluate the ACL in order, considering only ALLOW
+                and DENY ACEs for the identifier EVERYONE@ and for the
+                identifier under consideration.  The result of the evaulation
+                will be an NFSv4 ACL mask showing exactly which bits are
+                permitted to that identifier.
+            </t>
+
+            <t>
+                Then translate the calculated mask for OWNER@, GROUP@, and
+                EVERYONE@ into mode bits for, respectively, the user, group,
+                and other, as follows:
+
                 <list style="numbers">
                     <t>
-                        To determine MODE4_ROTH, MODE4_WOTH, and MODE4_XOTH:
-                        <list style="numbers">
-                            <t>
-                                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.
-                            </t>
-                            <t>
-                                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.
-                            </t>
-                            <t>
-                                If the special identifier EVERYONE@
-                                is granted ACE4_EXECUTE, then
-                                the bit MODE4_XOTH SHOULD be set.  Otherwise,
-                                MODE4_XOTH SHOULD NOT be set.
-                            </t>
-                        </list>
+                        Set the read bit (MODE4_RUSR, MODE4_RGRP, or
+                        MODE4_ROTH) if and only if ACE4_READ_DATA is set in
+                        the corresponding mask.
                     </t>
+
                     <t>
-                        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 just as ACEs with the special identifier
-                        GROUP@ would.
-                        <list style="numbers">
-                            <t>
-                                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.
-                            </t>
-                            <t>
-                                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.
-                            </t>
-                            <t>
-                                If the special identifier GROUP@ is granted
-                                ACE4_EXECUTE, then the bit MODE4_XGRP SHOULD
-                                be set. Otherwise, MODE4_XGRP SHOULD NOT be
-                                set.
-                            </t>
-                        </list>
+                        Set the write bit (MODE4_WUSR, MODE4_WGRP, or
+                        MODE4_WOTH) if and only if ACE4_WRITE_DATA and
+                        ACE4_APPEND_DATA are both set in the corresponding
+                        mask.
                     </t>
+
                     <t>
-                        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 just as ACEs with the special identifer
-                        OWNER@ would.
-                        <list style="numbers">
-                            <t>
-                                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.
-                            </t>
-                            <t>
-                                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.
-                            </t>
-                            <t>
-                                If the special identifier OWNER@ is granted
-                                ACE4_EXECUTE, then the bit MODE4_XUSR SHOULD
-                                be set. Otherwise, MODE4_XUSR SHOULD NOT be
-                                set.
-                            </t>
-                        </list>
+                        Set the execute bit (MODE4_XUSR, MODE4_XGRP, or
+                        MODE4_XOTH), if and only if ACE4_EXECUTE is set in the
+                        corresponding mask.
                     </t>
                 </list>
             </t>
-- 
1.5.0.3.31.ge47c

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 27 Mar 2007 18:48:41 -0400

The first paragraph is a little over-general: the only implementations
we know of, either in production or proposed, are just those including
permissions granted to named users and groups in the group mode bits.
It makes the first paragraph clearer if we focus on that single case.

I think the second paragraph is clearer after splitting the two cases
(getting and setting the mode) in to two separate paragraph, and after
providing a little explanation of the source of users' confusion.
---
 nfsv41_middle_fileattributes_acls.xml |   29 +++++++++++++++--------------
 1 files changed, 15 insertions(+), 14 deletions(-)

diff --git a/nfsv41_middle_fileattributes_acls.xml b/nfsv41_middle_fileattributes_acls.xml
index 27cf2e8..3af04b6 100755
--- a/nfsv41_middle_fileattributes_acls.xml
+++ b/nfsv41_middle_fileattributes_acls.xml
@@ -983,22 +983,23 @@
             </t>
             <section title="Discussion">
                 <t>
-                    The nine low-order mode bits (MODE4_R*, MODE4_W*, MODE4_X*)
-                    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 ACE4_WRITE_DATA, then
-                    MODE4_WGRP will be set, even though the file's owner_group
-                    is not granted ACE4_WRITE_DATA.
+                    Some server implementations also add bits permitted to
+                    named users and groups to the group bits (MODE4_RGRP,
+                    MODE4_WGRP, and MODE4_XGRP).
                 </t>
                 <t>
-                    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 semantic that setting the
-                    mode attribute effectively specifies read, write, and
-                    execute for owner, group, and other.
+                    Implementations are discouraged from doing this, because
+                    it has been found to cause confusion for users who see
+                    members of a file's group denied access that the mode
+                    bits appear to allow.  (The presence of DENY ACEs may also
+                    lead to such behavior, but DENY ACEs are expected to be
+                    more rarely used.)
+                </t>
+                <t>
+                    The same user confusion seen when fetching the mode also
+                    results if setting the mode does not effectively control
+                    permissions for the owner, group, and other users; this
+                    motivates some of the requirements that follow.
                 </t>
             </section>
         </section>
-- 
1.5.0.3.31.ge47c

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 27 Mar 2007 18:48:39 -0400

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 27 Mar 2007 18:48:40 -0400

-                                If the special idenFrom [email-masked] Tue Mar 27 18:49:54 2007
Date: Tue, 27 Mar 2007 18:48:39 -0400
Subject: [nfsv4] [PATCH 09/11] acls: shorten "The Inherited ACL"

-                    and those attributes contain an ACtifier OWNER@ is granted

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 27 Mar 2007 18:48:41 -0400

nfsv41_middle_fileattributes_acls.xml |   29 +++++++++++++++-----L attribute and/or a

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 27 Mar 2007 18:48:40 -0400

+                and---------

 other, as follows:
+
                 <list style="numbers">
                     <t>

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 27 Mar 2007 18:48:41 -0400

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 27 Mar 2007 18:48:34 -0400

RENAME and LINK are also affected by permissions that control adding or
removing things from directories.

VERIFY, NVERIFY, and READDIR may also be affected by READ_ATTRIBUTES.

EXECUTE on a directory could affect any operation that takes a path
component.  I've added the ones I thought of, though this may be going
a bit overboard.

Are WANT_DELEGATION or GET_DIR_DELEGATION likely to require any
permissions?  We should probably leave that up to the server
implementation.  Though I'm curious how you decide when a client should
be permitted to get notifications?

It's hard to get these lists right.  We should probably also add a
disclaimer stating that they aren't necessarily complete.
---
 nfsv41_middle_fileattributes_acls.xml |   11 +++++++++++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/nfsv41_middle_fileattributes_acls.xml b/nfsv41_middle_fileattributes_acls.xml
index b93af93..593154e 100755
--- a/nfsv41_middle_fileattributes_acls.xml
+++ b/nfsv41_middle_fileattributes_acls.xml
@@ -311,7 +311,9 @@
  ACE4_ADD_FILE
      Operation(s) affected:
          CREATE
+         LINK
          OPEN
+         RENAME
      Discussion:
          Permission to add a new file in a directory.  The CREATE
          operation is affected when nfs_ftype4 is NF4LNK, NF4BLK,
@@ -336,6 +338,7 @@
  ACE4_ADD_SUBDIRECTORY
      Operation(s) affected:
          CREATE
+         RENAME
      Discussion:
          Permission to create a subdirectory in a directory.  The
          CREATE operation is affected when nfs_ftype4 is NF4DIR.
@@ -370,6 +373,10 @@
          LOOKUP
          READ
          OPEN
+         REMOVE
+         RENAME
+         LINK
+         CREATE
      Discussion:
          Permission to execute a file or traverse/search a
          directory.
@@ -399,6 +406,7 @@
  ACE4_DELETE_CHILD
      Operation(s) affected:
          REMOVE
+         RENAME
      Discussion:
          Permission to delete a file or directory within a
          directory.  See section &quot;ACE4_DELETE vs. ACE4_DELETE_CHILD&quot;
@@ -407,6 +415,9 @@
  ACE4_READ_ATTRIBUTES
      Operation(s) affected:
          GETATTR of file system object attributes
+         VERIFY
+         NVERIFY
+From [email-masked] Tue Mar 27 18:49:54 2007
From: "J. Bruce Fields" <[email-masked]>
To: [email-masked]
Cc: 
Date: Tue, 27 Mar 2007 18:48:34 -0400
Subject: [nfsv4] [PATCH 04/11] acls: add to "operations affected" lists

RENAME and LINK are also affected by permissions that control adding or
removing things from directories.

VERIFY, NVERIFY, and READDIR may also be affected by READ_ATTRIBUTES.

EXECUTE on a directory could affect any operation that takes a path
component.  I've added the ones I thought of, though this may be going
a bit overboard.

Are WANT_DELEGATION or GET_DIR_DELEGATION likely to require any
permissions?  We should probably leave that up to the server
implementation.  Though I'm curious how you decide when a client should
be permitted to get notifications?

It's hard to get these lists right.  We should probably also add a
disclaimer stating that they aren't necessarily complete.
---
 nfsv41_middle_fileattributes_acls.xml |   11 +++++++++++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/nfsv41_middle_fileattributes_acls.xml b/nfsv41_middle_fileattributes_acls.xml
index b93af93..593154e 100755
--- a/nfsv41_middle_fileattributes_acls.xml
+++ b/nfsv41_middle_fileattributes_acls.xml
@@ -311,7 +311,9 @@
  ACE4_ADD_FILE
      Operation(s) affected:
          CREATE
+         LINK
          OPEN
+         RENAME
      Discussion:
          Permission to add a new file in a directory.  The CREATE
          operation is affected when nfs_ftype4 is NF4LNK, NF4BLK,
@@ -336,6 +338,7 @@
  ACE4_ADD_SUBDIRECTORY
      Operation(s) affected:
          CREATE
+         RENAME
      Discussion:
          Permission to create a subdirectory in a directory.  The
          CREATE operation is affected when nfs_ftype4 is NF4DIR.
@@ -370,6 +373,10 @@
          LOOKUP
          READ
          OPEN
+         REMOVE
+         RENAME
+         LINK
+         CREATE
      Discussion:
          Permission to execute a file or traverse/search a
          directory.
@@ -399,6 +406,7 @@
  ACE4_DELETE_CHILD
      Operation(s) affected:
          REMOVE
+         RENAME
      Discussion:
          Permission to delete a file or directory within a
          directory.  See section &quot;ACE4_DELETE vs. ACE4_DELETE_CHILD&quot;
@@ -407,6 +415,9 @@
  ACE4_READ_ATTRIBUTES
      Operation(s) affected:
          GETATTR of file system object attributes
+         VERIFY
+         NVERIFY
+         READDIR
      Discussion:
          The ability to read basic attributes (non-ACLs) of a file.
          On a UNIX system, basic attributes can be thought of as
-- 
1.5.0.3.31.ge47c

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 27 Mar 2007 18:48:32 -0400

The language in these two paragraphs is confusing.  I assume that "the
server can" is meant to be read "the server should be able to", but that
renders the first sentence of each paragraph a tautology.  The rest just
repeats that the ACL and mode most be compatible.

Also I think it overstates the case somewhat to say that "the ACL
attribute will describe all permissions on the file object."  Servers
may have other permissions mechanisms (like SELinux) that, though they
may not be visible to NFSv4 clients, will nevertheless be enforced.  We
shouldn't appear to prohibit that.

I think what's really intended is to require the ACL to be strictly more
powerful than the low-order mode bits; this enables users and
applications to move to a purely ACL-based permissions model by ensuring
that setattr and getattr of mode are never needed for anything other
than the 3 high-order bits.
---
 nfsv41_middle_fileattributes_acls.xml |   21 ++++++++-------------
 1 files changed, 8 insertions(+), 13 deletions(-)

diff --git a/nfsv41_middle_fileattributes_acls.xml b/nfsv41_middle_fileattributes_acls.xml
index 94cf875..dcc6403 100755
--- a/nfsv41_middle_fileattributes_acls.xml
+++ b/nfsv41_middle_fileattributes_acls.xml
@@ -65,19 +65,14 @@
                     discussions around them.
                 </t>
                 <t>
-                    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 <xref target="modeattr" />).
-                    The ACL attribute will not conflict with the mode
-                    attribute, on servers that support the mode attribute.
-                </t>
-                <t>
-                    If a se         READDIR
      Discussion:
          The ability to read basic attributes (non-ACLs) of a file.
          On a UNIX system, basic attributes can be thought of as
-- 
1.5.0.3.31.ge47c

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 27 Mar 2007 18:48:32 -0400

diff --git a/nfsv41_middle_fileattributes_acls.xml b/nfsv41_middle_fileattributes_acls.xml
index 94cf875..dcc6403 100755
--- a/nfsv41_middle_fileattributes_acls.xml
+++ b/nfsv41_middle_fileattributes_acls.xml
@@ -65,19 +65,14 @@
                     discussions around them.
                 </t>
                 <t>
-                    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 <xref target="modeattr" />).
-                    The ACL attribute will not conflict with the mode
-                    attribute, on servers that support the mode attribute.
-                </t>
-                <t>
-                    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.
+                    On servers that support both the mode and the ACL,
+                    the server must keep the two consistent with each other.
+                    The value of the mode attribute (with the exception of the
+                    three high order bits described in <xref
+                    target="modeattr" />), must be determined entirely
+                    by the value of the ACL, so that use of the mode is
+                    never required for anything other than setting the
+                    three high order bits.
                 </t>
                 <t>
                     When a mode attribute is set on an object, the ACL
-- 
1.5.0.3.31.ge47c

rver 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.
+                    On servers that support both the mode and the ACL,
+                    the server must keep the two consistent with each other.
+                    The value of the mode attribute (with the exception of the
+                    three high order bits described in <xref
+                    target="modeattr" />), must be determined entirely
+                    by the value of the ACL, so that use of the mode is
+                    never required for anything other than setting the
+                    three high order bits.
                 </t>
                 <t>
                     When a mode attribute is set on an object, the ACL
-- 
1.5.0.3.31.ge47c

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 27 Mar 2007 18:48:38 -0400

I'd prefer to consistently use "nine low-order mode bits" rather than
"bits that control permissions".
---
 nfsv41_middle_fileattributes_acls.xml |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/nfsv41_middle_fileattributes_acls.xml b/nfsv41_middle_fileattributes_acls.xml
index b41c578..7fc775e 100755
--- a/nfsv41_middle_fileattributes_acls.xml
+++ b/nfsv41_middle_fileattributes_acls.xml
@@ -1078,12 +1078,12 @@
                     either because the mode attribute was set or because 
                     the mode_set_masked attribute was set and the mask
                     included one or more bits from the low-order nine
-                    mode bits that control permissions, and the ACL
+                    mode bits, and the ACL
                     attribute is not explicitly set, the ACL
                     attribute must be modified in accordance with the
                     updated value of the permissions bits within the 
                     mode.  This must happen even if the value of the
-                    permission bits within the mode is the same after 
+                    nine low-order mode bits is the same after
                     the mode is set as before.
                 </t>
                 <t>
-- 
1.5.0.3.31.ge47c

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 27 Mar 2007 18:48:31 -0400

Fix some typos and minor grammar and style problems, and revise for
conciseness.
---
 nfsv41_middle_fileattributes_acls.xml |   44 +++++++++++++++-----------------
 1 files changed, 21 insertions(+), 23 deletions(-)

diff --git a/nfsv41_middle_fileattributes_acls.xml b/nfsv41_middle_fileattributes_acls.xml
index 454103b..94cf875 100755
--- a/nfsv41_middle_fileattributes_acls.xml
+++ b/nfsv41_middle_fileattributes_acls.xml
@@ -3,18 +3,18 @@
 <!-- Copyright (C) The Internet Society (2006) -->
 <section title="Access Control Lists" anchor="acl">
     <t>
-        Access Control Lists (ACLs) are a file attribute that specify fine
+        The Access Control List (ACL) is a file attribute that provides fine
         grained access control. This chapter covers the &quot;acl&quot;,
         &quot;dacl&quot;,
         &quot;sacl&quot;,
-        &quot;aclsupport&quot;, &quot;mode&quot;,
-        &quot;mode_set_masked&quot; file attributes, and
+        &quot;aclsupport&quot;, &quot;mode&quot;, and
+        &quot;mode_set_masked&quot; file attributes and
         their interactions.
     </t>
     
     <section title="Goals">
         <t>
-            ACLs and modes represent two well established but different models
+            ACLs and modes represent two well established models
             for specifying permissions. This chapter specifies requirements
             that attempt to meet the following goals:
 
@@ -50,7 +50,7 @@
                             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
+                            opens for read or write by any principal
                             fail, regardless of a previously existing or
                             inherited ACL.
                         </t>
@@ -140,8 +140,8 @@
                 Unlike the ALLOW and DENY ACE types, the ALARM and AUDIT ACE
                 types do not affect a requester's access, and instead are for
                 triggering events as a result of a requester's access attempt.
-                Therefore, all AUDIT and ALARM ACEs are processed until end of
-               From [email-masked] Tue Mar 27 18:49:54 2007
From: "J. Bruce Fields" <[email-masked]>
To: [email-masked]
Cc: 
Date: Tue, 27 Mar 2007 18:48:31 -0400
Subject: [nfsv4] [PATCH 01/11] acls: minor copyediting

Fix some typos and minor grammar and style problems, and revise for
conciseness.
---
 nfsv41_middle_fileattributes_acls.xml |   44 +++++++++++++++-----------------
 1 files changed, 21 insertions(+), 23 deletions(-)

diff --git a/nfsv41_middle_fileattributes_acls.xml b/nfsv41_middle_fileattributes_acls.xml
index 454103b..94cf875 100755
--- a/nfsv41_middle_fileattributes_acls.xml
+++ b/nfsv41_middle_fileattributes_acls.xml
@@ -3,18 +3,18 @@
 <!-- Copyright (C) The Internet Society (2006) -->
 <section title="Access Control Lists" anchor="acl">
     <t>
-        Access Control Lists (ACLs) are a file attribute that specify fine
+        The Access Control List (ACL) is a file attribute that provides fine
         grained access control. This chapter covers the &quot;acl&quot;,
         &quot;dacl&quot;,
         &quot;sacl&quot;,
-        &quot;aclsupport&quot;, &quot;mode&quot;,
-        &quot;mode_set_masked&quot; file attributes, and
+        &quot;aclsupport&quot;, &quot;mode&quot;, and
+        &quot;mode_set_masked&quot; file attributes and
         their interactions.
     </t>
     
     <section title="Goals">
         <t>
-            ACLs and modes represent two well established but different models
+            ACLs and modes represent two well established models
             for specifying permissions. This chapter specifies requirements
             that attempt to meet the following goals:
 
@@ -50,7 +50,7 @@
                             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
+                            opens for read or write by any principal
                             fail, regardless of a previously existing or
                             inherited ACL.
                         </t>
@@ -140,8 +140,8 @@
                 Unlike the ALLOW and DENY ACE types, the ALARM and AUDIT ACE
                 types do not affect a requester's access, and instead are for
                 triggering events as a result of a requester's access attempt.
-                Therefore, all AUDIT and ALARM ACEs are processed until end of
-                the ACL.
+                Therefore, all AUDIT and ALARM ACEs are processed until the
+                end of the ACL.
             </t>
             <t>
                 The NFS version 4 ACL model is quite rich. Some server
@@ -200,9 +200,9 @@
                     <c>ACE4_SYSTEM_AUDIT_ACE_TYPE</c>
                     <c>AUDIT</c>
                     <c>
-                        LOG (system dependent) any access attempt to a file or
-                        directory which uses any of the access methods
-                        specified in acemask4.
+                        LOG (in a system dependent way) any access attempt to
+                        a file or directory which uses any of the access
+                        methods specified in acemask4.
                     </c>
                     <c>ACE4_SYSTEM_ALARM_ACE_TYPE</c>
                     <c>ALARM</c>
@@ -214,7 +214,7 @@
                     <postamble>
                         The &quot;Abbreviation&quot; column denotes how the
                         types will be referred to throughout the rest of this
-                        document.
+                        chapter.
                     </postamble>
                 </texttable>
             </section>
@@ -667,7 +667,7 @@
                                     <vspace />
                                     The ACE4_SUCCESSFUL_ACCESS_ACE_FLAG
                                     (SUCCESS) and ACE4_FAILED_ACCESS_ACE_FLAG
-                                    (FAILED) flag bits relate only to
+                                    (FAILED) flag bits may be set only on
                                     ACE4_SYSTEM_AUDIT_ACE_TYPE (AUDIT) and
                                     ACE4_SYSTEM_ALARM_ACE_TYPE (ALARM) ACE
                                     types. If during the processing of the
@@ -694,14 +694,12 @@
 
                                 <t hangText="">
                                     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.
+                                    applies to ACCESS operations even when
+                                    they return NFS4_OK.  For the purposes of
+                                    AUDIT and ALARM, we consider an ACCESS
+                                    operation to be a "failure" if it fails
+                                    to return a bit that was requested and
+                                    supported.
                                 </t>
 
                                 <t hangText="ACE4_IDENTIFIER_GROUP">
@@ -783,8 +781,8 @@
                 </texttable>
                 <t>
                     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
+                    distinguished by an appended "@" and should appear in the
+                    form "xxxx@" (with no domain name after the "@"). For
                     example: ANONYMOUS@.
                 </t>
 
@@ -1299,7 +1297,7 @@
                     from being affected by ACEs meant for non-directories.
                 </t>
                 <t>
-                    If when a new directory is created and it inherits ACEs
+                    When a new directory is created and it inherits ACEs
                     from its parent, for each inheritable ACE which affects
                     the directory's permissions, a server MAY create two AC the ACL.
+                Therefore, all AUDIT and ALARM ACEs are processed until the
+                end of the ACL.
             </t>
             <t>
                 The NFS version 4 ACL model is quite rich. Some server
@@ -200,9 +200,9 @@
                     <c>ACE4_SYSTEM_AUDIT_ACE_TYPE</c>
                     <c>AUDIT</c>
                     <c>
-                        LOG (system dependent) any access attempt to a file or
-                        directory which uses any of the access methods
-                        specified in acemask4.
+                        LOG (in a system dependent way) any access attempt to
+                        a file or directory which uses any of the access
+                        methods specified in acemask4.
                     </c>
                     <c>ACE4_SYSTEM_ALARM_ACE_TYPE</c>
                     <c>ALARM</c>
@@ -214,7 +214,7 @@
                     <postamble>
                         The &quot;Abbreviation&quot; column denotes how the
                         types will be referred to throughout the rest of this
-                        document.
+                        chapter.
                     </postamble>
                 </texttable>
             </section>
@@ -667,7 +667,7 @@
                                     <vspace />
                                     The ACE4_SUCCESSFUL_ACCESS_ACE_FLAG
                                     (SUCCESS) and ACE4_FAILED_ACCESS_ACE_FLAG
-                                    (FAILED) flag bits relate only to
+                                    (FAILED) flag bits may be set only on
                                     ACE4_SYSTEM_AUDIT_ACE_TYPE (AUDIT) and
                                     ACE4_SYSTEM_ALARM_ACE_TYPE (ALARM) ACE
                                     types. If during the processing of the
@@ -694,14 +694,12 @@
 
                                 <t hangText="">
                                     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.
+                                    applies to ACCESS operations even when
+                                    they return NFS4_OK.  For the purposes of
+                                    AUDIT and ALARM, we consider an ACCESS
+                                    operation to be a "failure" if it fails
+                                    to return a bit that was requested and
+                                    supported.
                                 </t>
 
                                 <t hangText="ACE4_IDENTIFIER_GROUP">
@@ -783,8 +781,8 @@
                 </texttable>
                 <t>
                     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
+                    distinguished by an appended "@" and should appear in the
+                    form "xxxx@" (with no domain name after the "@"). For
                     example: ANONYMOUS@.
                 </t>
 
@@ -1299,7 +1297,7 @@
                     from being affected by ACEs meant for non-directories.
                 </t>
                 <t>
-                    If when a new directory is created and it inherits ACEs
+                    When a new directory is created and it inherits ACEs
                     from its parent, for each inheritable ACE which affects
                     the directory's permissions, a server MAY create two ACEs
                     on the directory being created; one effective and one
-- 
1.5.0.3.31.ge47c

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 27 Mar 2007 18:48:37 -0400

I understand there was some confusion which motivated adding this
section.  However, in the current draft I believe the definition of
EVERYONE@ below, and the discussion in "Setting the mode and/or ACL
Atributes", addresses the problem more than adequately, and a separate
section is no longer necessary.
---
 nfsv41_middle_fileattributes_acls.xml |   10 ----------
 1 files changed, 0 insertions(+), 10 deletions(-)

diff --git a/nfsv41_middle_fileattributes_acls.xml b/nfsv41_middle_fileattributes_acls.xml
index fc67844..b41c578 100755
--- a/nfsv41_middle_fileattributes_acls.xml
+++ b/nfsv41_middle_fileattributes_acls.xml
@@ -771,16 +771,6 @@
                     example: ANONYMOUS@.
                 </t>
 
-                <section title="Discussion of EVERYONE@">
-                    <t>
-                        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.
-                    </t>
-                </section>
             </section>
         </section>
         <section title="dacl and sacl Attributes" anchor="daclsacl">
-- 
1.5.0.3.31.ge47c

Es

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 27 Mar 2007 18:48:37 -0400