Subject: RE: Update to ACL processing description

From: "Yoder, Alan" <[email-masked]>
Date: Tue, 2 Nov 1999 11:40:45 -0800

> Based on input from Carl Beame, I have updated the I-D to include
> this new description of processing an NFS ACE:
> 
>   "To determine if an ACCESS or OPEN request succeeds each nfsace4 entry
>    is processed in order by the server.  Only ACEs which have a "who"
>    that matches the requestor are considered.  Each ACE is processed
>    until all of the bits of the requestor's access have been ALLOWED.
>    Once a bit (see below) has been ALLOWED by an ACCESS_ALLOWED_ACE, it
>    is no longer considered in the processing of later ACEs. If an
>    ACCESS_DENIED_ACE is encountered where the requestor's mode still has
>    unALLOWED bits in common with the "access_mask" of the ACE, the
>    request is denied."

   Sorry to be pesky about this, but this still deviates from the NT
standard.  Is that intentional?  In NT, encountering an ACCESS_DENIED_ACE
which matches any bit of the requested access causes the request to fail,
regardless of what allowed bits have been accumulated, so long as the
ACCESS_DENY_ACE is encountered before *all* the requested ALLOWED bits have
all been accumulated.
   The above can be brought into compliance with NT as follows:

   "To determine if an ACCESS or OPEN request succeeds each nfsace4 entry
    is processed in order by the server.  Only ACEs which have a "who"
    that matches the requestor are considered.  Each ACE is processed
    until all of the bits of the requestor's access have been ALLOWED.
    If, before this happens, an ACCESS_DENIED_ACE is encountered where 
    the requestor's mode has bits in common with the "access_mask" of 
    the ACE, the request is denied."

   I also am wondering (perhaps a bit late), whether the permissions
bits are supposed to allow servers to emulate AFS ACLs?  It looks to
me like "rlwida" are covered, though some suitable #defines to specify
the necessary combinations would perhaps be welcome.  I can suggest
those if it is wanted.  What about "k", though?  Is "SYNCHRONIZE" 
supposed to cover that?  How about the eight programmatically definable 
masks "A" through "H"?  Should we include placeholders for those?

Alan

===============================================================
Alan G. Yoder                                    [email-masked]
Network Appliance, Inc.                           
Santa Clara, CA  95051                             408-822-6919
===============================================================

---

From: Gordon W Waidhofer <[email-masked]>
Date: Tue, 02 Nov 1999 13:35:14 -0800

>    The above can be brought into compliance with NT as follows:

Are you sure about this? The MAXIMUM_ALLOWED algorithm seems to imply
the contrary.
> masks "A" through "H"?  Should we include placeholders for those?

This begs a fair question. It is also a difficult question. Should
NFSv4 define a file model? Should it accomodate a variety of file
models? The problem is that the ACL model drags in a lot of other
non-file stuff, like SID vs UID/GID. I tend to approach such questions
in terms of commercial viability. Does AFS matter? Does NT matter (duh)?
I don't know a compelling answer. I just wanted to frame the question.

---

From: Carl Beame <[email-masked]>
Date: 02 Nov 1999 23:35:38 +0000

> ACCESS_DENY_ACE is encountered before *all* the requested ALLOWED bits

This is not true. I placed the following ACLs on a file and was
allowed Read/Write access:

allow Read group1
deny Read group2
allow Write group3

For a user who is a member of all three groups Read Write access is
allowed. (This was tested programmatically). BUT you should note that
the Windows 2000 GUI places all DENY ACLs before ALLOW ACLs giving the
behaviour that you described above.

That is just a feature of the GUI. If you use a different program to
set the ACLs NT behaves as I described.

- Carl