Subject: Re: [nfsv4] ACL mode bit descriptions in minorversion1-02

From: Lisa Week <[email-masked]>
Date: Mon, 01 May 2006 20:11:08 -0600

J. Bruce Fields wrote:

>On Fri, Apr 28, 2006 at 09:16:03AM -0600, Lisa Week wrote:
>  
>
>>J. Bruce Fields wrote:
>>    
>>
>>>Could we remove the "Operation(s) affected:" sections from 3.16.2?
>>>
>>>      
>>>
>>If it is deemed not useful, sure, we can remove them.  Ultimately, the 
>>purpose of that section is to clarify what each mode bit controls and we 
>>thought it was useful to explain what each controlled in the form of NFS 
>>operations.
>>    
>>
>
>Sure.
>
>  
>
>>Allowing or denying the the READ is in the bounds of the current fh.  If 
>>the file that the READ is destined for has a deny READ_DATA ACE, that 
>>READ is denied.
>>
>>Are you talking about the relationship between READ_DATA and EXECUTE?
>>    
>>
>
>Yes--I assume servers will still need to permit read whenever they
>permit execute, as has always been the case with previous NFS versions.
>Ours does.
>  
>
Right. Our server also permits read when it permits execute.

>The other case I was thinking of was owner overrides--we generally allow
>the owner to bypass permissions checks to reduce the chance of failure
>when the openmode and permissions disagree.  (E.g., I create a file with
>an open that initializes the mode to 0; or I open and then chmod
>afterwards.)  The explicit on-the-wire opens in NFSv4 reduce the chance
>of this sort of problem but don't eliminate it.
>
>>From a quick look at our nfsd permissions code I only saw these two
>cases, but there may be some others I've overlooked.
>  
>
Yes, I see your point on both of these, but I haven't decided what the 
best thing to do would be.

In both of these cases we potentially have the problem of the ACL saying 
one thing and the server enforcing the other.  Right?  In this situation 
you are relying on the client to enforce the access.

Is this what you had in mind when you recommended adding a discussion on 
the client's part in enforcing access?

>  
>
>>>Also some discussion of the client's part in enforcing access might be
>>>useful--NFSv4 doesn't completely remove the need for the client to do
>>>so.
>>>      
>>>
>>I'll have to think about this, but that seems useful, but I am not sure 
>>if I agree with the part about NFSv4 doesn't completely remove the need 
>>for the client to do so...
>>
>>The problem is that in RFC3530 there is text like the following:
>>
>>"Although, the client can read and write the ACL attribute, the NFSv4 model 
>>is the server does all access control based on the
>>server's interpretation of the ACL."
>>    
>>
>
>Right.  That's why we provide the ACCESS operation--it gives the client
>a way to enforce access without having to evaluate any ACLs itself.
>With ACCESS, the client can just asks the server to evaluate the ACL for
>it.
>
>  
>
Yes.  Understood.

Thanks,
Lisa

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

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 2 May 2006 10:24:09 -0400

> the client's part in enforcing access?

Yes.  The current language gives the impression that ACL enforcement is
performed purely by the server allowing or forbidding certain NFSv4
operations.  I think that over-simplifies.

But maybe it would be enough just to add a paragraph with a brief
description of the cases we know about.  Sorry that I don't have
language to propose....

--b.

---

From: Lisa Week <[email-masked]>
Date: Tue, 02 May 2006 16:47:46 -0600

>description of the cases we know about.  Sorry that I don't have

I'll take a stab at it and we can work from there...

Thanks,
Lisa

---

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

Lisa Week wrote:

>>> In both of these cases we potentially have the problem of the ACL 
>>> saying one thing and the server enforcing the other.  Right?  In 
>>> this situation you are relying on the client to enforce the access.
>>>
>>> Is this what you had in mind when you recommended adding a 
>>> discussion on the client's part in enforcing access?
>>>   
>>
>>

The client's role in access checking:

------
Clients must be aware of situations in which an object's ACL will define 
a certain access even though the server will not enforce it.  In 
general, but especially in these situations, the client needs to do its 
part in the enforcement of access as defined by the ACL.  To do this, 
the client may issue the appropriate ACCESS operation prior to servicing 
the request of the user or application in order to determine whether the 
user or application should be granted the access requested.

Known situations in which the ACL may define accesses that the server 
doesn't enforce:

o Many UNIX-based servers will allow a user the ability to read the data 
of the file when only the execute permission is granted (i.e. If the ACL 
denies the user the ACE4_READ_DATA access and allows the user 
ACE4_EXECUTE, the server will allow the user to read the data of the 
file).  XXX should we add the reason?

o Many servers have the notion of owner-override in which the owner of 
the object is allowed to override accesses that are denied by the ACL. 
XXX again, should we add the reason/rationale?
------
Comments?

Thanks,
Lisa

---

From: Benny Halevy <[email-masked]>
Date: Tue, 16 May 2006 19:09:13 +0300

How about letting the client read data when it has 
write-only access?  This is required for clients that do 
read-modify-write on partial-page updates.
In this case the client OS needs to make sure that the data 
stays in its cache and not returned to users without 
permission to read it.

Benny

---

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

> XXX again, should we add the reason/rationale?

Looks helpful, thanks.

Are the two "Many"'s there actually "all"?  I don't see what else a
server could do....

--b.

---

From: Benny Halevy <[email-masked]>
Date: Tue, 16 May 2006 19:54:34 +0300

> Are the two "Many"'s there actually "all"?  I don't see what else a

Yeah, there's no EXECUTE call or OPEN mode in NFS so the 
server has no way to know if the file is being read for 
execute or just for fun :-)

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 16 May 2006 13:03:26 -0400

> Are the two "Many"'s there actually "all"?  I don't see what else a

OK, sorry, that's probably not a very helpful suggestion.  Could we put
some SHOULD's or MUST's in there?  (E.g., "Servers SHOULD allow a user
the ability to read the data of the file when only the execute
permission is granted.")

--b.

---

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

>the ability to read the data of the file when only the execute
So my question:

Is this text supposed to be 1.) a specification of the server behavior 
or 2.) documentation of the implementation considerations for the client 
(i.e. have clients consider the fact that they may need to do access 
checking via ACCESS as well)?

I thought it was the second, we can decide.  I think there is a fine 
line here and we just have to clarify the goal.

Thanks,
- Lisa

---

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

> line here and we just have to clarify the goal.

I don't know.  I think this would be useful information to have in the
spec, so I suppose it's a question of which organization is clearest.
If you think there's a better place for it, I don't suppose I have a
strong opinion.

--b.

---

From: Sam Falkner <[email-masked]>
Date: Tue, 16 May 2006 15:01:50 -0600

> If you think there's a better place for it, I don't suppose I have a

How about if the server part of the discussion (1. above) were put in  
the
part that discusses each of the access_mask bits?  I think that would be
easiest.

- Sam