NFSv4 ACL mapping and unintentional deny

J. Bruce Fields bfields at fieldses.org
Wed Feb 22 22:29:57 GMT 2006


On Tue, Feb 21, 2006 at 06:21:56PM -0600, Steven French wrote:
> I find the links below helpful and they seem accurate based on my
> experience

Thanks!

> "The system examines each ACE in sequence until one of the following events
> occurs:
>       An access-denied ACE explicitly denies any of the requested access
>       rights to one of the trustees listed in the thread's access token.
>       One or more access-allowed ACEs for trustees listed in the thread's
>       access token explicitly grant all the requested access rights.
>       All ACEs have been checked and there is still at least one requested
>       access right that has not been explicitly allowed, in which case,
>       access is implicitly denied."

Hm, so there's a subtle difference between the two; consider a Windows
ACL like:

	ALLOW user1 read
	DENY user1 read
	ALLOW user1 write

The above requires that we deny a request for read and write permissions
to user1.  (Even though we would grant seperate requests for either read
permissions or write permissions!)

This isn't the case if we interpret the above as an NFSv4 ACL; from
rfc3530: "once a bit... has been ALLOWED by and ACCESS_ALLOWED_ACE, it
is no longer considered in the processing of later ACEs."  So the DENY
ace above is superfluous in the NFSv4 case.

In fact there exists no NFSv4 ACL that acts like the Windows ACL above;
all NFSv4 ACLs have the property that they permit any combination of
permission bits if and only if they would permit each of them
individually (ignoring the undefined case where some bits are neither
allowed nor denied).

> which seems correct.   Also note an interesting recent paper that I just
> spotted explaining some of the Windows model and the ways common mistakes
> applications make (some of these considerations could apply to
> non-Windows):
>       http://www.cs.princeton.edu/~sudhakar/papers/winval.pdf

That's interesting, thanks.  And a good argument for keeping things
simple, if there's any hope of that at this point....

--b.


More information about the samba-technical mailing list