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

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 27 Apr 2006 16:05:12 -0400

Could we remove the "Operation(s) affected:" sections from 3.16.2?

I understand the desire for a more detailed explanation of mode bit
semantics, but I don't think a bare list of operations with each mode
bit really helps.

For example, it doesn't tell how exactly the listed operations are
affected, which is often the more interesting question.  (Which READs
exactly are disallowed by denying READ_DATA?  Owner overrides and
execute permissions make the answer more complicated than expected.)

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.

Like the per-operation lists of error codes, these lists are going to be
hard to maintain--there will be inevitable omissions, and additional
maintenance will be required when new operations are added.  That energy
might be better targetted to focused explanations of difficult
implementation issues.

If we do decide to keep it, it needs to be carefully checked for
completeness.  Currently, for example, I think it's missing:
	RENAME
	SETATTR of the size attribute
	the effect of EXECUTE on read permissions

--b.

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

---

From: Lisa Week <[email-masked]>
Date: Fri, 28 Apr 2006 09:16:03 -0600

Hi Bruce,

>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.

>semantics, but I don't think a bare list of operations with each mode
Okay.

>exactly are disallowed by denying READ_DATA?
>
Hmmm... I am not sure what you mean by this, but perhaps there were 
underlying assumptions.

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?

>Owner overrides and

Actually, I think we should try to enumerate these issues.  Would you be 
able to give a little more info about what you are thinking about here?

If it is complicated it is probably the case that others will or have 
had problems with it...

>useful--NFSv4 doesn't completely remove the need for the client to do

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."

So I don't quite know if there is consensus on the fact that the client 
may need to enforce access...  That is something that should be addressed.

>completeness.
Agreed.

>Currently, for example, I think it's missing:
>	RENAME
Noted.

Thanks,
Lisa

---

From: "J. Bruce Fields" <[email-masked]>
Date: Fri, 28 Apr 2006 11:32:44 -0400

> thought it was useful to explain what each controlled in the form of NFS 

Sure.

> 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.

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.

> "Although, the client can read and write the ACL attribute, the NFSv4 model 
> is the server does all access control based on the

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.

--b.