Subject: RE: [nfsv4] DELETE_CHILD and DELETE

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 3 Feb 2004 12:30:45 -0800

> For summary, my interpretation is that DELETE_CHILD refers to
> the directory contents and DELETE refers to the file's contents.

Make sense to me.

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

I think you need WRITE_ATTRIBUTES on the file to decrement the link
count, when the link count is greater than one.  I suppose you need
it if you are decrementing the link count from 1 to zero and keeping
the file aroung (for example whie it is open).

I agree that when the link count was 1, you need DELETE on the file.

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

Since the spec distinguishes ADD_FILE and DELETE_CHILD, you have 
that case anyway.  I'm also assuming that if a directory allows one of
those but not the other, you cannot rename a file within the directory.
Fun, huh?

> Still, I do not think the spec can or should mandate these semantics,
> but rather recommend them.

As long as it gives clear guidelines about what to do, I really
don't care if they are offered as mandates or recommendations.

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

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.

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.

Benny

> -----Original Message-----
> From: Noveck, Dave [mailto:[email-masked]]
> Sent: Tuesday, February 03, 2004 2:46 PM
> To: J. Bruce Fields; [email-masked]
> Subject: RE: [nfsv4] DELETE_CHILD and DELETE
> 
> 
> > 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?)
> 
> Not that I could see.
> 
> > I'm assuming that removal is allowed if *either* 
> DELETE_CHILD or DELETE
> > is set, 
> 
> That doesn't seem right to me.  If the owner of the directory let's me
> write in it, OK.  But if the owner of the file doesn't let me 
> do anything
> with it (read, write, execute), why would I be allowed to delete the
> thing, especially since there is an explicit DELETE bit by which I may
> prohibit people from doing a delete?
> 
> It would seem more natural to me if both were required, but I didn't
> see any text that addressed the issue.
> 
> > in which case posix implementations should associate
> > DELETE_CHILD with write permissions and should never set DELETE.
> 
> -----Original Message-----
> From: J. Bruce Fields [mailto:[email-masked]]
> Sent: Tuesday, February 03, 2004 12:57 PM
> To: [email-masked]
> Subject: [nfsv4] DELETE_CHILD and DELETE
> 
> 
> 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
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nfsv4
> 

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

---

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

> the file aroung (for example whie it is open).

You really don't want to require WRITE_ATTRIBUTES for any operation that
might modify the attributes of a file.

In fact, I was assuming that our linux client should set
WRITE_ATTRIBUTES for the file's owner only.  (Does WRITE_ATTRIBUTES also
give the right to modify mode bits?)

--b.