Subject: RE: [nfsv4] Re: [NFS] NFSv4 ACL and POSIX interaction / mask, draft-ietf-nfsv4-acls-00 not ready

From: "Yoder, Alan" <[email-masked]>
Date: Fri, 14 Jul 2006 12:26:29 -0700

> > >> For a client that doesn't support the new attributes, a 
> > >> server can apply
> > >> the mask attributes to the ACL before returning it.  I suppose a
> > >> multi-protocol server would do the same for CIFS clients.
> > >> 
> > Since CIFS does not understand the semantics of permission 
> mask, does
> > the server enforce the mask when the access for the data comes from
> > a CIFS client ?
> 
> Yes, it does.  But it also only ever shows CIFS clients a 
> version of the
> ACL with the mask already applied, so CIFS clients see no 
> inconcistency.
> (In other words, if there's an "ALLOW bfields READ+WRITE" ACE, but the
> relevant mask only allows READ, then the CIFS client will see 
> a version
> of the ACL where that ACE only allows READ.)
> 
> See any reason why that won't work?

Let me see if I understand.

A POSIX ACL client sees ALLOW bfields READ+WRITE
A *nix client that only does perms sees r
A client that only does CIFS sees ALLOW bfields READ

If I have that right, this is like going straight to hell 
for a multi-protocol server company.  Does that qualify
as a reason for why this won't work?

Alan

===============================================================
Alan G. Yoder                                    [email-masked]
Technical Staff                           
Network Appliance, Inc.                            408-822-6919
===============================================================

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

---

From: "J. Bruce Fields" <[email-masked]>
Date: Fri, 14 Jul 2006 15:43:51 -0400

> A POSIX ACL client sees ALLOW bfields READ+WRITE

Not necessarily "POSIX ACL" clients, but clients that request the new
mask attributes.  Such clients also understand that the relevant mask
makes that ALLOW effectively the same as just an allow of READ.

> A *nix client that only does perms sees r

In the group bit, yes.

> A client that only does CIFS sees ALLOW bfields READ

Right.

> for a multi-protocol server company.

Why?  As far as I can tell, for the multi-protocol server it's a mild
improvement over the current situation.

Right now any client attempting to do posix-draft ACL's (or implementing
full NFSv4 ACLs and strictly adhering to posix requirements on
permissions mechanisms) is setting ACLs with complicated interleaved
DENYs and ALLOWs that, I'm told, no reasonable Windows application is
going to be able to make head or tails of.

My revision of the posix acl draft allows such clients to do that kind
of thing less often.

But Andreas's proposal removes the need for clients to do that stuff in
many more cases.  And the server-side implementation seems doable.

--b.