RE: Atomic MOVE and move permissions

> 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