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

bfields@fieldses.org

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

On Wed, Dec 15, 2004 at 03:46:36PM -0500, Halevy, Benny wrote:
> Thinking about this again, the following model
> makes even more sense to me:
> 
> - everyone can always read named attributes.
> - the owner can always write named attributes.
> - anyone that has permission to write the file
>   has permission to write its named attributes.
> 
> - permission to write named attributes applies
> to the contents of named attributes as well
> as to creating, removing, and renaming named
> attributes.

I don't know whether that makes sense.  My goal here isn't really to
figure out how named attribute permissions should work.

The problems I'm currently trying to address are:

	1. Some nfsv4 servers don't implement the full NFSv4 ACL protocol.
	   The Linux server, for example, is supporting POSIX acls only for
	   the time being, because that's all our backend filesystems support.
	2. It's easy to expose full NFSv4 ACLs to users on clients.
	   However, a number of clients have preexisting POSIX ACL
	   interfaces, and want to continue supporting applications and
	   users that may depend on them.

For example, I'd like it to be possible for a user to set a posix acl on
a file over NFSv4.  This requires translating the posix acl they provide
into an NFSv4 acl whose effect is something like what they'd expect.

The best thing in this case may be to leave
{READ,WRITE}_NAMED_ATTRIBUTES completely unspecified and leave it up the
the server.  On a linux server that will have the same effect as the
current mapping, since there's no way for a linux server to decouple
{READ,WRITE}_NAMED_ATTRIBUTES from read/write permissions.  On another
server that may have some other effect.

In fact, it may be that we should throw out this whole complicated
specification of mode bits and just use:

	r->READ_DATA
	w->WRITE_DATA
	x->EXECUTE

Since the server behaviour is undefined when bits are left unspecified,
we could leave all the bits other than READ_DATA, WRITE_DATA, and
EXECUTE unset in every allow and deny ace, and depend on the server to
do the right thing.

Most of the language in our draft about what NFSv4 mode bits should be
set would then become recommendations about how servers should determine
what to do when they fall off the bottom of an acl, if they want to
provide posix-like clients the permissions they expect.

For example, if an ACL allows WRITE, and doesn't deny APPEND_DATA, then
a server should by default allow APPEND_DATA.  If an ACL doesn't deny
WRITE_ATTRIBUTES to the owner then the client should assume it's
permitted.  Etc.

In fact, I rather like that idea.  It seems a great deal simpler than
what we have now.  Objections?

--b.

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