From: Eric Sedlar (eric.sedlar@oracle.com)
Date: 11/27/02-06:30:51 PM Z
Message-ID: <010b01c29675$68329280$9a114498@us.oracle.com> From: "Eric Sedlar" <eric.sedlar@oracle.com> Subject: ACL ordering Date: Wed, 27 Nov 2002 16:30:51 -0800 One issue that has come out in the ACL spec we're standardizing for WebDAV is the issue about restricting ACE order in an ACL. While it isn't enforced by the Windows kernel, all Windows clients force any deny ACEs to come before the grant ACEs. This avoids weird processing errors such as the following list of ACEs: <grant READ> <deny READ> <grant WRITE> Now, if I ask NT for read permission, I get it, since the evaluation short circuits after the first ACE. If I ask NT for write permission, I get it, since the first two ACEs are ignored. If I ask NT for read AND write permission, the request is denied, since I don't have all the permission I need after the first ACE, and the second ACE will cause the access check to fail. Therefore, to really achieve Windows interoperability (let alone usability), protocols like NFSv4 should avoid allowing deny ACEs after any grant ACEs. This also relaxes the requirement to maintain strict ACE ordering, since ordering is irrelevant when processing denies, and ordering is irrelevant when processing grants (other than as an optimization). I didn't see anything in the spec about what order the inherited ACEs should be placed in (for example relative to a default ACL that might be defined on the server on a per-user basis), so making this ordering requirement clear simplifies the work. --Eric
This archive was generated by hypermail 2.1.2 : 03/04/05-01:50:32 AM Z CST