Subject: RE: [nfsv4] DELETE_CHILD and DELETE

From: "Halevy, Benny" <[email-masked]>
Date: Tue, 3 Feb 2004 18:17:36 -0500

>So a posix client could get the behavior it expects by always setting
>DELETE, and setting DELETE_CHILD only on directories wherever the write
>bit is set?

yes, posix requires only write permission on the directory
see http://www.opengroup.org/onlinepubs/007904975/functions/unlink.html
  ...
  [EACCES] 
  Search permission is denied for a component of the path prefix, or write
  permission is denied on the directory containing the directory entry to
  be removed. 

see also my reply to [email-masked] in
ftp://ftp.ietf.org/ietf-mail-archive/nfsv4/2003-08.mail
Message-ID: <[email-masked]>

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

Benny

>-----Original Message-----
>From: J. Bruce Fields [mailto:[email-masked]]
>Sent: Tuesday, February 03, 2004 3:32 PM
>To: Halevy, Benny
>Cc: 'Noveck, Dave'; [email-masked]
>Subject: Re: [nfsv4] DELETE_CHILD and DELETE
>
>
>On Tue, Feb 03, 2004 at 03:07:03PM -0500, Halevy, Benny wrote:
>> What about REMOVE when link count is greater than one?
>> 
>> In this case you are modifying the directory but you aren't 
>> deleting the object and I'd expect the file system to allow
>> that if you have DELETE_CHILD (or WRITE if DELETE_CHILD is
>> not specifically supported) access to the directory,
>> regardless of whether you have DELETE access to the
>> file.
>> 
>> If the client is about to obliterate the file by removing its
>> last link then it should need both DELETE_CHILD access to the
>> directory and DELETE access to the file.
>> 
>> For summary, my interpretation is that DELETE_CHILD refers to
>> the directory contents and DELETE refers to the file's contents.
>> 
>> Since REMOVE always modifies the directory, you should always need
>> DELETE_CHILD access on the directory.  When the file's link count
>> is 1 you should also need DELETE access to the file.
>
>So a posix client could get the behavior it expects by always setting
>DELETE, and setting DELETE_CHILD only on directories wherever the write
>bit is set?
>
>I suppose that would work.  Do you have a source for this
>interpretation?  Are there server implementations that actually work
>this way?
>
>> If you always require both it could lead to an unpleasant case
>> where you can link a file to a directory but cannot unlink it.
>> Still, I do not think the spec can or should mandate these semantics,
>> but rather recommend them.
>
>If I sit down at a client to set certain mode bits or acls I don't want
>to have read all the client and server documentation to work out what
>those acls actually mean.  That sounds like a security nightmare.
>
>--Bruce Fields
>

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

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 3 Feb 2004 18:48:18 -0500

> 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.

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 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?

---Bruce Fields