Subject: [nfsv4] DELETE_CHILD and DELETE

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

If and acl allows DELETE_CHILD is set on a directory and denies DELETE
on a file in the directory, is it documented anywhere whether the file
should be removeable? (and what if it denies DELETE_CHILD and allows
DELETE on the file?)

I'm assuming that removal is allowed if *either* DELETE_CHILD or DELETE
is set, in which case posix implementations should associate
DELETE_CHILD with write permissions and should never set DELETE.

--Bruce Fields

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

---

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 3 Feb 2004 14:38:56 -0800

> I'm also a little confused as to whether WRITE_ATTRIBUTES should control
> the ability to write the size attribute.

Why is that confusing?  All you have to do is figure out whether the
size is a "basic attribute".  Maybe we can do a pH test :-)

-----Original Message-----
From: J. Bruce Fields [mailto:[email-masked]]
Sent: Tuesday, February 03, 2004 5:16 PM
To: Jim Rees
Cc: [email-masked]
Subject: Re: [nfsv4] DELETE_CHILD and DELETE

On Tue, Feb 03, 2004 at 04:21:35PM -0500, Jim Rees wrote:
>   I think you need WRITE_ATTRIBUTES on the file to decrement the link
>   count, when the link count is greater than one.
> 
> No, I don't think so.  WRITE_ATTRIBUTES is for those attributes that are
> explicitly set by the client, the ones marked R/W in section 5.5 of the rfc.

Except that there's a specific exception in the rfc, which says
WRITE_ATTRIBUTES controls "The ability to write basic attributes
(non-acls) of a file".

"basic attributes" isn't a term that's defined anywhere; reading this
text you might assume it just meant attributes other than acls, but I
think it was intended to mean attributes other than named attributes.

Of course if WRITE_ATTRIBUTES allows writing of mode bits, then in
practice it *does* allow writing of acls.  So perhaps mode bits should
also be excepted.

I'm also a little confused as to whether WRITE_ATTRIBUTES should control
the ability to write the size attribute.

--Bruce Fields

---

From: "Halevy, Benny" <[email-masked]>
Date: Wed, 4 Feb 2004 09:56:23 -0500

(resending to the alias)

-----Original Message-----
From: Halevy, Benny 
Sent: Tuesday, February 03, 2004 8:16 PM
To: 'J. Bruce Fields '; Halevy, Benny
Cc: ''Noveck, Dave' '; [email-masked] '
Subject: RE: [nfsv4] DELETE_CHILD and DELETE

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

---

From: Wu Zheng <[email-masked]>
Date: Wed, 4 Feb 2004 11:30:18 -0600

I agree with what you have.  I want to add the following.

A user can alter a file's mode or ACL only when he/she has the
ACE4_WRITE_ACL permission.
A file's mode can be read when the user has ACE4_READ_ATTRIBUTES or
ACE4_READ_ACL permission.
A file's ACL can be read when the user has ACE4_READ_ACL permission.

Wu Zheng
[email-masked]
Phone: (512) 838-0558    T/L: 678-0558
11400 Burnet Road,  Austin, TX 78758

"Halevy, Benny" <[email-masked]>@ietf.org on 02/04/2004 08:56:23 AM

Sent by:    [email-masked]

To:    "[email-masked]'" <[email-masked]>
cc:
Subject:    RE: [nfsv4] DELETE_CHILD and DELETE

(resending to the alias)

-----Original Message-----
From: Halevy, Benny
Sent: Tuesday, February 03, 2004 8:16 PM
To: 'J. Bruce Fields '; Halevy, Benny
Cc: ''Noveck, Dave' '; [email-masked] '
Subject: RE: [nfsv4] DELETE_CHILD and DELETE

J. Bruce Fields 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.

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.