Subject: proposed text for ACL amgiguity issue

From: Mike Eisler <[email-masked]>
Date: Thu, 29 Aug 2002 14:05:09 -0700

> in writing up a proposed method to map POSIX and NFSv4 ACLs, i more
> closely exacmined the ACL text in the RFC.  i find the following to be
> ambiguous:
> 
>    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 requester are considered.  Each ACE is processed
>    until all of the bits of the requester's access have been ALLOWED.
>    Once a bit (see below) has been ALLOWED by an ACCESS_ALLOWED_ACE, it
> 
>    is no longer considered in the processing of later ACEs. If an
>    ACCESS_DENIED_ACE is encountered where the requester's mode still has
>    unALLOWED bits in common with the "access_mask" of the ACE, the
>    requet is denied.
> 
> the ambiguitiy lies in that it does not specify what to do if the
> requested access mask was not all ALLOWed, but also not DENYed.  i
> have always assumed to deny in this case, but it is not clear.  if
> this is the case, i propose to add the following sentence:
> 
>    When the ACL is is fully processed, if there are remaining
>    unALLOWed bits in the mask, the request is denied.
> 
> marius.

CHANGE:

   To determine if a request succeeds, each nfsace4 entry is processed
   in order by the server.  Only ACEs which have a "who" that matches
   the requester are considered.  Each ACE is processed until all of the
   bits of the requester's access have been ALLOWED.  Once a bit (see
   below) has been ALLOWED by an ACCESS_ALLOWED_ACE, it is no longer
   considered in the processing of later ACEs. If an ACCESS_DENIED_ACE
   is encountered where the requester's access still has unALLOWED bits
   in common with the "access_mask" of the ACE, the request is denied.
   However, unlike the ALLOWED and DENIED ACE types, the ALARM and AUDIT
   ACE types do not affect a requestor's access, and instead are for
   triggering events as a result of a requestor's access attempt.
   Therefore, all AUDIT and ALARM ACEs are processed until end of the
   ACL.

TO:

   To determine if a request succeeds, each nfsace4 entry is processed
   in order by the server.  Only ACEs which have a "who" that matches
   the requester are considered.  Each ACE is processed until all of the
   bits of the requester's access have been ALLOWED.  Once a bit (see
   below) has been ALLOWED by an ACCESS_ALLOWED_ACE, it is no longer
   considered in the processing of later ACEs. If an ACCESS_DENIED_ACE
   is encountered where the requester's access still has unALLOWED bits
   in common with the "access_mask" of the ACE, the request is denied.
   However, unlike the ALLOWED and DENIED ACE types, the ALARM and AUDIT
   ACE types do not affect a requestor's access, and instead are for
   triggering events as a result of a requestor's access attempt.
   Therefore, all AUDIT and ALARM ACEs are processed until end of the
   ACL. When the ACL is fully processed, if there are
   bits in requestor's mask that have not been considered
   whether the server allows or denies the access is
   undefined. If there is a mode attribute on the file,
   then this cannot happen, since the mode's MODE4_*OTH
   bits will map to terminating EVERYONE@ ACEs that
   unambigously specify the requestor's access.