Atomic MOVE and move permissions

> > Actually, collection MOVE suffers from the same problems as 
> collection
> > DELETE.  Here are some of them.
> >  - You can't MOVE a file you don't have permission to 
> write. Therefore,
> > the server must check write privileges on all descendants.
> 
> I think I disagree. I *can* MOVE a resource without having 
> write permissions
> to the resource itself. What I need is the write permission 
> on source and
> targer collection (+ some more when overwriting something else).

That's really interesting.  This is a tangent, but an important one, I
think.  I had assumed that if I have 'write' permission on a collection
"home/", but I do *not* have write permission on an internal member
"foo.txt", that an attempt to MOVE home/foo.txt (either to another
collection or a rename) would fail.  In the absence of the ACL
specification, my assumption is as good as yours!  

Now, I did check the ACL specification to see how servers supporting
that specification would have to behave. I don't think the ACL
specification is totally clear on that issue.  Is this a bug in the ACL
draft?  Even if we can't specify one or the other, the ACL draft should
specify that a user may or may not need write permission specifically on
a resource to move it, as well as write permission to the source and
target parent collections.

But back to the atomic vs. non-atomic move, the permissions example was
just an example.  You still have to recursively check privileges on all
descendent _collections_ if one accepts your permissions model.  And you
still have to recursively check locks, etc.  The basic argument for
non-atomic move was that in some situations, the server will have to
implement it as a super-user COPY-->DELETE.

> Yes, that's why many people would prefer it to fail (leaving 
> the client the
> choice to explicitly COPY/DELETE) rather than doing something 
> the client
> din't really want.

Right, but did you read the part about how the server might be able to
do a much better job of the under-the-cover copy-and-delete than the
client possibly could?  A client can only do operations based on its
authenticated context, whereas the server process may have more power to
change things.  My first example, and it's only one of many, was that a
client may not have permission to set "creationdate" but a server
obviously can.  So if the server accomplishes the MOVE by doing a
copy-and-delete behind the scenes, the server can clean up
"creationdate" so that it's the date of the original resource. However,
the client may not be allowed to set the value of "creationdate" to the
most correct value after it does a manual COPY operation.

Lisa

Received on Saturday, 8 March 2003 14:03:24 UTC