From: Khan, Saadia (Saadia.Khan@netapp.com)
Date: 01/10/05-07:52:14 PM Z
Subject: RE: [nfsv4] NFSv4 ACLs: {READ,WRITE}_NAMED_ATTRIBUTES
Date: Mon, 10 Jan 2005 17:52:14 -0800
Message-ID: <482A3FA0050D21419C269D13989C611303D87B1D@lavender-fe.eng.netapp.com>
From: "Khan, Saadia" <Saadia.Khan@netapp.com>
> -----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?
Saadia
_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4
This archive was generated by hypermail 2.1.2 : 03/04/05-02:13:50 AM Z CST