- From: Lisa Dusseault <lisa@xythos.com>
- Date: Sat, 8 Mar 2003 11:03:21 -0800
- To: "'Julian Reschke'" <julian.reschke@gmx.de>, "'WebDAV'" <w3c-dist-auth@w3.org>
- Cc: <acl@webdav.org>
> > 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