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

Lisa.Week@Sun.COM

Date: Tue, 11 Jan 2005 10:02:04 -0600
From: Lisa Week <Lisa.Week@Sun.COM>
Subject: Re: [nfsv4] NFSv4 ACLs: {READ,WRITE}_NAMED_ATTRIBUTES
Message-id: <41E3F87C.1030501@Sun.COM>

Khan, Saadia wrote:
> 
>>-----Original Message-----
>>From: J. Bruce Fields [mailto:bfields@fieldses.org] 
>>Sent: Monday, January 10, 2005 1:02 PM
>>To: Sam Falkner
>>Cc: nfsv4@ietf.org; Lisa Week
>>Subject: Re: [nfsv4] NFSv4 ACLs: {READ,WRITE}_NAMED_ATTRIBUTES
>>
>>
>>On Fri, Jan 07, 2005 at 04:46:55PM -0700, Sam Falkner wrote:
>>
>>>This document describes what the Solaris NFSv4 Server will 
>>
>>accept for 
>>
>>>ACLs when it must map to POSIX-draft ACLs for a UFS filesystem.
>>
>>That all looks OK to me.  I only see one minor practical 
>>problem, with {READ,WRITE}_NAMED_ATTRIBUTES.
>>
>>I think what you've chosen to do (allow anything except 
>>explicit DENY's of {READ,WRITE}_NAMED_ATTRIBUTES) is the 
>>right thing given what you've said about the security model 
>>for Sun's named attributes (which is that the only thing acls 
>>and mode bits on the file can affect is the default 
>>permission of associated streams on the file).  But currently 
>>I think that will cause interoperability problems with 
>>Netapp--the permissions on a newly created file on a Netapp 
>>server will include DENY's to entity without read and write 
>>permissions, so your client will have to decide what to do in 
>>that case.  (You don't really discuss client-side behaviour, 
>>though, so maybe you'll be more lenient there.)
> 
> 
> Yes, that is correct, if a file does not have read/write perms, we will
> map that to an acl which will deny generic read/write perms which
> include {READ,WRITE}_NAMED_ATTRIBUTES. What would the solaris client do
> in that case?
> 

The Solaris client will ignore the {READ,WRITE}_NAMED_ATTRS...it won't
fail just because it sees it in a DENY.  Although, when setting ACLs
from our client, we will never set {READ,WRITE}_NAMED_ATTRS in any ACE.

- Lisa & Sam

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