Re: [nfsv4] NFSv4 ACLs: {READ,WRITE}_NAMED_ATTRIBUTES

New Message Reply About this list Date view Thread view Subject view Author view Attachment view

From: J. Bruce Fields (bfields@fieldses.org)
Date: 12/16/04-05:18:30 PM Z


Date: Thu, 16 Dec 2004 18:18:30 -0500
Subject: Re: [nfsv4] NFSv4 ACLs: {READ,WRITE}_NAMED_ATTRIBUTES
Message-ID: <20041216231830.GK7357@fieldses.org>
From: "J. Bruce Fields" <bfields@fieldses.org>

On Thu, Dec 16, 2004 at 04:00:51PM -0700, Lisa Week wrote:
> J. Bruce Fields wrote:
> >On Thu, Dec 16, 2004 at 11:42:26AM -0800, Gordon Waidhofer wrote:
> >
> >>The question of NFSV4_{READ|WRITE}_NAMED_ATTRIBUTES
> >>should be deferred for as long as possible, certainly
> >>in the near term. Why? Simply because there is unspoken
> >>discord about what a named attribute is.
> >
> >I agree about the {READ|WRITE}_NAMED_ATTRIBUTES bits.
> >
> 
> Just to be clear...What are we actually saying with "The question of 
> NFSV4_{READ|WRITE}_NAMED_ATTRIBUTES should be deferred for as long as 
> possible"?  Go with the I-D interpretation?  Leave them unspecified? 
> Something else?

I think we should recommend that on posix->nfsv4 translation, we create
acls with neither bit set in any allow or deny ace.  On nfsv4->posix
translation we should ignore that bit whenever possible, that is,
whenver it doesn't force us into a lie.  (A Linux server, for example,
will reject an acl that explicitly denies WRITE_NAMED_ATTRIBUTES
when WRITE is explicitly allowed.)

I think that's approximately what we already agreed on?

The point is that if clients follow the current I-D then they force a
certain permissions model onto servers, which is probably a mistake.

--b.

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4


New Message Reply About this list Date view Thread view Subject view Author view Attachment view

This archive was generated by hypermail 2.1.2 : 03/04/05-02:13:48 AM Z CST