Re: [nfsv4] NFSv4 ACLs: ACE4_WRITE_ATTRIBUTES clarification

bfields@fieldses.org

Date: Wed, 15 Dec 2004 15:43:18 -0500
Subject: Re: [nfsv4] NFSv4 ACLs: ACE4_WRITE_ATTRIBUTES clarification
Message-ID: <20041215204318.GD30441@fieldses.org>
From: "J. Bruce Fields" <bfields@fieldses.org>

On Wed, Dec 15, 2004 at 02:43:34PM -0500, J. Bruce Fields wrote:
> So I think that the current proposal for how to use the 14 bits in v4
> ace bitmasks when mapping between v4 and posix acls is this:

I've also been trying to think about how to make nfsv4->posix mapping
more forgiving, and how to simplify acl management in the case where
both posix and nfsv4 user acl utilities are available.

Currently if I touch a file and ask for its nfsv4 acl this is what I
get:

$ touch /mnt/puzzle/test1/FOO
$ nfs4_getfacl /mnt/puzzle/test1/FOO 
1: A::OWNER@:rwanNtTcCy
2: D::OWNER@:x
3: A:g:GROUP@:rntcy
4: D:g:GROUP@:waNxTC
5: A::EVERYONE@:rntcy
6: D::EVERYONE@:waNxTC

All that just to say the equivalent of "rw-r--r--".  Ugh!

It's hard to interpret, and harder still to modify, especially if the
server will reject anything that doesn't have every single bit set
correctly.

We could make the server mapping more forgiving by performing a
few transformations on the input nfsv4 acl before mapping it to a posix
acl:
	1. If the DENY aces created by the posix->nfsv4 mapping are
	   left out, recreate them as necessary.  (We're erring on the
	   side of denying permissions, which is safe.)
	2. If the input nfsv4 acl fails to either allow or deny some
	   bit, then permit ourselves to allow or deny those bits as
	   necessary to make the mapping work.  (Behaviour is undefined
	   when we neither allow nor deny, so we're free to do what we
	   want.)

A server that did both of these would be able to handle an acl as simple
as:

A::OWNER@:rw
A::GROUP@:r
A::EVERYONE@:r

instead of requiring an acl like the above.

Clients doing posix mapping could similarly accept such simplified acls
from servers[1].  Which might make it reasonable for servers to actually
return such acls.  That would mean users wouldn't have to see the full
6-ace acl above, when the server was really only dealing with posix
acls.

A server that actually did deal with full nfsv4 acls couldn't return the
simplified versions.  But in that case all those extra bits would *mean*
something, and could be independently modified by the user.

Comments?

--b.

Footnote:
[1] Actually, not quite: it shouldn't perform step #1 in all cases, as
it may lead to misrepresenting an acl as more secure than it really is.
So deny aces would still be necessary, e.g., in the case of r--rw-rw-,
since

A::OWNER@:r
A::GROUP@:rw
A::EVERYONE@:rw

is more permissive than the corresponding posix acl, since it doesn't
deny write to the owner.

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