Subject: RE: [nfsv4] DELETE_CHILD and DELETE

From: "Halevy, Benny" <[email-masked]>
Date: Tue, 3 Feb 2004 15:07:03 -0500

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:31:55 -0500

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

> 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