Subject: RE: [nfsv4] DELETE_CHILD and DELETE

From: "Halevy, Benny" <[email-masked]>
Date: Tue, 3 Feb 2004 20:16:19 -0500

J. Bruce Fields wrote:
> 
> On Tue, Feb 03, 2004 at 06:17:36PM -0500, Halevy, Benny wrote:
> > I believe that a Posix compliant nfsv4 client should create an ACE for
> > the file OWNER to allow it ACE4_WRITE_{ATTRIBUTES,ACL} |
> ACE4_WRITE_OWNER
> > and an ACE for EVERYONE to allow ACE4_READ_{ATTRIBUTES,ACL} and ACE4_DELETE
> > (when supported by the server).
> > ...
> > I believe that the correct mappings should be:
> > Posix read:     ACE4_READ_DATA | ACE4_LIST_DIRECTORY
> > Posix write:    ACE4_WRITE_DATA | ACE4_ADD_FILE | ACE4_APPEND_DATA |
> >                 ACE4_ADD_SUBDIRECTORY | ACE4_DELETE_CHILD
> > Posix execute:  ACE4_READ_DATA | ACE4_LIST_DIRECTORY | ACE4_EXECUTE
> 
> I agree, except that I think we also need to add READ_NAMED_ATTRIBUTES and WRITE_NAMED_ATTRIBUTES to posix read and posix write, respectively.

How would a POSIX client access named attribtues?
I think that it would be acceptable if chmod() or creat() on a posix client leave {READ,WRITE}_NAMED_ATTRIBUTES unchanged and let named attributes capable clients to maintain them.

> 
> There's also a problem with WRITE_ATTRIBUTES: if you need it to modify the size, then WRITE_ATTRIBUTES should be set for whoever has write access; but if it also permits modification of mode bits then you give complete control of the file to anyone you give write access to.

I agree.  Setting the size is considered a data modifying operation
and it makes sense that it will be controlled by ACE4_WRITE_ACL.
I'm not absolutely sure whether this should be in addition to ACE4_WRITE_ATTRIBUTES or not.

> 
> I think WRITE_ATTRIBUTES should not apply to the size, the mode bit, named attributes, acls, or to any attribute modifications that are a
> side-effect of some other operation (e.g. writing and reading change modification and (possibly) access times, and unlinking and linking change nlinks, but these operations shouldn't require
WRITE_ATTRIBUTES.).
> 
> Note that GENERIC_READ, GENERIC_WRITE, and GENERIC_EXECUTE are in any case completely wrong; is there any chance of just getting them deleted from the rfc, or is it too late for that?

Good question...  If anyone is using them for any other purpose we might want to add POSIX_READ, POSIX_WRITE, and POSIX_EXECUTE.

> ---Bruce Fields

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 4 Feb 2004 13:06:25 -0500

On Tue, Feb 03, 2004 at 08:16:19PM -0500, Halevy, Benny wrote:
> > I agree, except that I think we also need to add READ_NAMED_ATTRIBUTES
> > and WRITE_NAMED_ATTRIBUTES to posix read and posix write, respectively.
> 

That's not standardized as far as I know, but I'm assuming that POSIX
clients that implement named attributes expect them to be treated like
file/directory data for permissions purposes.  I believe this is true at
least on Linux and FreeBSD.

> I think that it would be acceptable if chmod() or creat() on a posix
> client leave {READ,WRITE}_NAMED_ATTRIBUTES unchanged and let named
> attributes capable clients to maintain them.

The problem is that a server using POSIX ACL's on the exported
filesystem to implement a subset of NFSv4 ACL's can't leave it to
clients to maintain the NAMED_ATTRIBUTES bits because the server doesn't
have any way of storing the NAMED_ATTRIBUTES bits; it's stuck mapping an
incoming NFSv4 ACL to a POSIX ACL and then mapping back when it
retrieves the ACL.  So it's going to have to return an ACL that
consistently either includes the NAMED_ATTRIBUTES bits or doesn't.  I
believe the latter default makes more sense.

> > Note that GENERIC_READ, GENERIC_WRITE, and GENERIC_EXECUTE are in
> > any case completely wrong; is there any chance of just getting them
> > deleted from the rfc, or is it too late for that?
> 
> Good question...  If anyone is using them for any other purpose we
> might want to add POSIX_READ, POSIX_WRITE, and POSIX_EXECUTE.

I don't know of any purpose that anyone could be using them for that
would be correct.  They aren't referred to anywhere in the rfc outside
their definition, so deleting them should be trivial.  It would be easy
for a reader of the rfc to get the impression that they provide a
sensible way of synchronizing ACL's with mode bits, but they don't, so
they seem like a trap for unwary implementors.

--Bruce Fields