Subject: [nfsv4] default-DENY policy and v4.0/v4.1 interoperability

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 4 May 2006 16:37:05 -0400

The current 4.1 draft recommends switching to a default-deny
policy--currently if you reach the end of an ACL without a particular
bit being allowed or denied, server behavior is undefined; in 4.1 the
server would deny access.

A 4.0 client (like a Windows client) that wants default-deny must
automatically append an EVERYONE@ DENY ACE, then later, on querying the
ACL, strip off such trailing DENY's before displaying the ACL to the
user.

With 4.1 such a client could omit appending the DENY ACE, but must still
be ready to strip off trailing DENYs when reading ACLs, which are likely
to be there for ACLs originally written by 4.0 clients.  (Or should a
server strip off trailing DENY's itself before returning an ACL to a 4.1
client?)

Is the only point of the change to save 4.1 clients from doing this kind
of translation?  I wonder if it's worth it, especially if it doesn't
actually remove the need completely?

Also, it may be worth thinking about what an OSX implementation would
do--OSX appears to support NFSv4/Windows-like ACLs, but without
default-deny (instead they consult the mode bits after the ACL):

http://developer.apple.com/documentation/Security/Conceptual/Security_Overview/Concepts/chapter_3_section_9.html

--b.

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

---

From: Rusty Tucker <[email-masked]>
Date: Thu, 4 May 2006 17:07:34 -0700

> default-deny (instead they consult the mode bits after the ACL):

... and if the mode bits fail to grant the necessary privilege, the  
request is denied.

One can think of the mode bits in Mac OS X as an extension to the ACL  
( if that  helps ).  The default-deny still exists, just as it does  
with permissions set by mode bits alone.

An OS X implementation of NFSv4 ACLs  would quite likely perform a  
conversion similar to that which we do in Samba for SMB clients.   
Synthesize ACEs to provide the clients what they expect, but store  
permissions in our native format locally.  Mac OS X would not locally  
need the DENY everyone as described above.

In our Samba case the Mac OS X mode bits are expressed ( to the  
extent necessary ) as additional ACEs at the end of the ACL when the  
ACL is requested by a SMB client.   For example,  if the mode bits  
are 000, no additional ACEs are necessary, if the mode bits are 007  
an ACE granting Everyone rwx access is added to the list.

When a Windows client sets the ACL, our original Samba implementation  
set the Mac OS X ACL as defined by the client and set the local mode  
bits to 000.  This was very 'clean' in terms of ACLs, but was a bit  
confusing to applications accessing the same files over NFSv3!

The shipping implementation preserves as much of the mode bits as  
possible, with an option to revert to the original behavior.  So,  
when ACEs are encountered that apply to the file's owner, group or  
everyone; they are mapped to mode bits and set.  This turned out to  
be a compromise that customers
seem happy with.

For those interestedm the code that performs this conversion is in  
darwin <http://www.opensource.apple.com/darwinsource/10.4.6.ppc/ 
samba-92.19/darwin_vfs/>

Hope this helps,

Rusty Tucker
Apple Computer

>
> http://developer.apple.com/documentation/Security/Conceptual/ 
> Security_Overview/Concepts/chapter_3_section_9.html
>
> --b.
>

---

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 4 May 2006 20:34:56 -0400

> with permissions set by mode bits alone.

Sure. I just worry about how much complexity the protocol requirements
force: after you're done adjusting the ACL and mode bits to arrange for
the default deny and for the rfc3530 requirement that ACL and mode bits
are kept synchronized, the resulting behavior may be too complicated to
explain to users any more....

> darwin <http://www.opensource.apple.com/darwinsource/10.4.6.ppc/ 

Neat, thanks.--b.

---

From: Lisa Week <[email-masked]>
Date: Tue, 16 May 2006 09:31:06 -0600

Hi Bruce,

>server would deny access.
So, I am not discounting the fact that RFC3530 says that if you reach 
the end of an ACL without a particular bit being allowed or denied, the 
server behavior is undefined, but I wonder how many servers actually 
rely on that.  It seems that most will fall into the behavior of denying 
accesses that aren't specified by the ACL.  Of course there are always 
exceptions, but perhaps it would be good to focus on why the behavior 
was left undefined in the first place.

In other words, does it really make sense?

>ACL, strip off such trailing DENY's before displaying the ACL to the

Is this the behavior of Windows clients today?

>actually remove the need completely?
In general, the point is to have a clear definition of what it means to 
"fall of the end of an ACL".  In other words, having a behavior defined 
(that everyone can agree on) for when the ACL doesn't specify a certain 
access will create a world in which the clients can rely on a common 
behavior.

>http://developer.apple.com/documentation/Security/Conceptual/Security_Overview/Concepts/chapter_3_section_9.html

Thanks,
Lisa

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 16 May 2006 12:30:57 -0400

On Tue, May 16, 2006 at 09:31:06AM -0600, Lisa Week wrote:
> rely on that.
....
> Is this the behavior of Windows clients today?

I don't know; maybe not.  But from a careful reading of 3530, it looks
like that that's what they *should* be doing.

So I'm just trying to figure out what to advise the careful windows
client implementor to do.  I suspect you're right that in practice we
can rely on servers, even servers that don't advertise 4.1 support, to
enforce default deny.  But it makes me nervous to advise clients to
count on behavior that's not mandated by the spec.

One way to settle the question might be to decide whether it would be
OK to put the default-deny requirement into the revised 4.0 spec.  If
so, great.

> access will create a world in which the clients can rely on a common 

Sure.  In the case where different clients and servers have different
security models, though, we need to make sure that over-specifying
behavior doesn't force them to lie.

For example, consider the single-ACE ACL

	ALLOW bfields READ|WRITE|APPEND.

With a default deny policy this would appear to implicity deny
READ_ATTRIBUTES, but I'd rather a server be permitted to accept such an
ACL even if it has no intention of enforcing the deny of
READ_ATTRIBUTES.

In fact, I'd rather the server be allowed to accept such an ACL even if
*explicitly* denies READ_ATTRIBUTES--the fact is some servers simplfy
have no idea what the READ_ATTRIBUTES permission means, and our choice
is to either allow them to ignore it or force the client/user to
discover the server's security model by trial and error.

If we could agree to allow the server to ignore that sort of thing then
I'd be much less worried about default deny.

--b.

---

From: [email-masked]
Date: Tue, 16 May 2006 14:22:16 -0400

>> -----Original Message-----
>> From: Lisa Week [mailto:[email-masked]] 
>> Sent: Tuesday, May 16, 2006 11:31
>> To: J. Bruce Fields
>> Cc: [email-masked]
>> Subject: Re: [nfsv4] default-DENY policy and v4.0/v4.1 
>> interoperability
>> 
>> Hi Bruce,
>> 
>> J. Bruce Fields wrote:
>> 

EMC Celerra deny access when access control reaches the end of the ACL
and 
There is not enough information for the server to make a decision

 It seems that most will fall into the 
>> behavior of denying 

No. Windows does not automatically append a deny ACE. In a Windows
envrionment,
when the server is unable to reach a conclusion whether to allow or deny
access,
it denies access to the file.
>> >http://developer.apple.com/documentation/Security/Conceptual
>> /Security_Overview/Concepts/chapter_3_section_9.html
>> >
>> >
>> >  
>> >
>> 
>> Thanks,
>> Lisa
>>

---

From: [email-masked]
Date: Tue, 16 May 2006 14:24:19 -0400

>> From: J. Bruce Fields [mailto:[email-masked]] 
>> Sent: Tuesday, May 16, 2006 12:31
>> To: Lisa Week
>> Cc: [email-masked]
>> client implementor to do.

Good luck in trying to convince them to change the behavior of something
That has been working for quite a while

  I suspect you're right that in practice we

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 16 May 2006 14:45:17 -0400

On Tue, May 16, 2006 at 02:24:19PM -0400, [email-masked] wrote:
From: J. Bruce Fields [mailto:[email-masked]] 
> >> > > A 4.0 client (like a Windows client) that wants default-deny
> >> > > must automatically append an EVERYONE@ DENY ACE, then later, on
> >> > > querying the ACL, strip off such trailing DENY's before
> >> > > displaying the ACL to the user.

On Tue, May 16, 2006 at 09:31:06AM -0600, Lisa Week wrote:
> >> I don't know; maybe not.  But from a careful reading of 3530, it
> >> looks like that that's what they *should* be doing.
> >> 
> Good luck in trying to convince them to change the behavior of
> something That has been working for quite a while

OK, so we have a situation where some clients are making an unwarranted
assumption, but it doesn't matter because the assumption is correct for
all the servers we know of.  So there are two solutions:

	1. Require servers to conform to the assumption.

	2. Fix the clients.

A paranoid person would advocate both, I suppose.  I agree that #1 would
be simpler.  But if we're going to do that, then I think we should:

	1. Do this for 4.0, not just 4.1.  If we are in practice
	requiring default deny in 4.0, then we need to make this
	explicit; otherwise it's a trap for future server implementors.

	2. Make sure the default deny policy isn't a straightjacket for
	servers that don't support all mode bits.

--b.