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

bfields@fieldses.org

Date: Wed, 15 Dec 2004 16:19:14 -0500
Subject: Re: [nfsv4] NFSv4 ACLs: {READ,WRITE}_NAMED_ATTRIBUTES
Message-ID: <20041215211914.GE30441@fieldses.org>
From: "J. Bruce Fields" <bfields@fieldses.org>

On Wed, Dec 15, 2004 at 03:26:27PM -0500, Halevy, Benny wrote:
> Bruce, why do you map the {READ,WRITE}_NAMED_ATTRIBUTES
> to the {r,w} permission bits which control access
> to the file's *data* rather than mapping them the
> same as {READ,WRITE}_ATTRIBUTES - read allowed by
> everyone, write allowed to owner?

I checked Linux and (if I remember correctly) FreeBSD, and they both
used the {r,w} permission bits.

I'd welcome examples of unix-like OS's that do something different.

> Since the NFS client determines what's
> stored in the file's named attributes

On Linux at least most named attributes are controlled by userspace, not
by the nfs client specifically, and those that aren't (system.posix_acl
and system.posix_acl are currently the only ones we care about) I expect
to be handled as special cases on the client.

> I think that coupling named attrs permission with *data* r/w
> permission is wrong as I assume that the contents of the named
> attributes are going to be client O/S or application *metadata* like
> filename in 8.3 format, file description, author, track #, etc.

In the last 3 of your examples, at least, it only makes sense to me to
couple the attribute permissions with data read/write permissions, since
those attributes are likely to need updating when the file contents
change.

Any change in the posix<->nfsv4 acl mapping should be in the direction
of just leaving out the NAMED_ATTRIBUTES bits entirely rather than
allowing to the owner and denying to others.

--b.

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