- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Sat, 8 Mar 2003 20:16:06 +0100
- To: "Lisa Dusseault" <lisa@xythos.com>, "'Julian Reschke'" <julian.reschke@gmx.de>, "'WebDAV'" <w3c-dist-auth@w3.org>
- Cc: <acl@webdav.org>
> From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Saturday, March 08, 2003 8:03 PM > To: 'Julian Reschke'; 'WebDAV' > Cc: acl@webdav.org > Subject: 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! Yes. Eric, could you please publish the latest state of the ACL spec (which includes the required-permission-per-method table)? > 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. I think a rename operation should not require write access to the resource itself (it only affects the state of the parent collection). I also think this was the consensus of the attendees of the January meeting. > 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 Why? > still have to recursively check locks, etc. The basic argument for Yes. > non-atomic move was that in some situations, the server will have to > implement it as a super-user COPY-->DELETE. Yes. And the basic argument for RENAME is that in some cases a client doesn't *wan't* that to happen, because the resulting resource may behave differently than the original. > > 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. Yes. That's why the current proposal says that MOVE can use the RFC2518 semantics, while REBIND will be really atomic. Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Saturday, 8 March 2003 14:16:23 UTC