RE: Locking questions

See Below

> -----Original Message-----
> From: Jim Whitehead [mailto:ejw@ics.uci.edu]
> Sent: Thursday, July 09, 1998 3:08 PM
> To: WEBDAV WG
> Subject: FW: Locking questions
> 
> 
> Accidentally sent to the -request address.
> 
> - Jim
> 
> -----Original Message-----
> From: Jim Amsden [mailto:jamsden@us.ibm.com]
> Sent: Thursday, July 09, 1998 12:26 PM
> To: w3c-dist-auth-request@w3.org
> Subject: Locking questions
> 
> 
> I have some detailed questions about locking as described in 
> version 08 of
> the
> WebDAV spec. Any help would be greatly appreciated.
> 
> Section 5.1: is there any intent for lock scope to apply 
> across lock types?
> For
> example, if a server supported read locks, could a user take out an
> exclusive
> write lock on a resource that is read locked by another user? 
> Or are the
> semantics across lock types dependent on the lock type and 
> defined by the
> server? If so, how could these semantics be discovered through a
> supportedlock
> property?
> 

The answer is 100% dependent on the lock type. As for discovery, a new lock
type would need to specify how one discovers any behaviors it has beyond
those supported in the WebDAV spec.

> Section 7.10.1, last sentence says: "The response MUST 
> contain the value of
> the
> lockdiscovery property in a prop XML element". What exactly is in the
> lockdiscovery property returned on a successful LOCK? Is it 
> the activelock
> just
> granted, or the same activelocks that would be returned by a 
> lockdiscovery
> PROPFIND? If it is the latter, how would an application 
> determine which lock
> token was just granted to the user? The owner element in the 
> lockdiscovery
> is
> not sufficient because it does not necessarily indicate the 
> credentials of
> the
> owner of the lock but rather gives contact information 
> suitable for human
> interpretation. If it is the former, then there's no problem 
> as there is
> exactly one locktoken in the lockdiscovery for a successful 
> LOCK, and it's
> the
> one just granted.
> 

The response must include the current value of the lockdiscovery property.
As the lockdiscovery property lists all locks outstanding against the
resource then the prop element must contain the same list.

The application would determine the appropriate lock token by examining the
response and finding the lock entry that matches what it requested. Thus if
you asked for an exclusive write lock and got back a 200 response then the
lock token associated with the exclusive write lock must be yours. The same
logic applies to shared write locks. There is no possibility of ambiquity
for write locks. If another lock type does have the possibility of ambiquity
then it will have to add additional response elements to compensate.

> In a follow-up question to the above, how would an application
> programatically
> determine the credentials (the user id from the Authorization 
> header using
> the
> Basic or Digest authorization scheme)? A lockdiscovery 
> PROPFIND will return
> the
> owner, but this isn't necessarily the authorization credentials? Is it
> intended
> to hide this information? If so, then applications are responsible for
> retaining locktokens for all resources they have locked until 
> they no longer
> need them. For example, if an application obtained an 
> exclusive write lock
> on a
> resource with infinite time-out, and subsequently lost the 
> locktoken, there
> would be no way for the owner to unlock the resource without 
> becoming the
> admin
> user.
> 

Auth schemes are a nasty business without any rule on how one can reliably
identify a particular principal. Thus DAV choose to side step the problem
for the moment feeling that a useful system could be implemented without
having to provide a mechanism for identifying principals. Part of this "side
step" however was accepting the responsibility to solve the problem as part
of the DAV ACL effort. Two drafts, one on requirements and another on a
potential implementation are available in the drafts directory.

However there is a temporary hack which can be used until the ACL draft is
standardized. The Owner element is completely specified by the client and
may contain anything. Thus one can imagine an application submitting an
owner element of the form: <owner>This lock was taken out by
Michael<unique-id><href>guid:1234-4342-234-234234</href></unique-id></owner>
.

> Section 6.5 describes the problem of race conditions 
> resulting from multiple
> concurrent processes acting under the same principal on the 
> same resources.
> I
> do not understand why requiring locktokens for all resources 
> modified by a
> method solves this problem. I assume a scenario like the 
> following would be
> typical: Program A takes out a lock on Resource A for User A, 
> and retains
> the
> lock token returned by the LOCK method. At some subsequent 
> point it time,
> Program A communicates the locktoken to another program, 
> Program B, also run
> by
> User A, as Program B cannot discover the locktoken itself 
> (due to the issues
> described above). Now Program A and Program B are equally 
> able to modify
> Resource A. Resource A is it is locked by User A, and both 
> Program A and
> Program
>  B have the locktoken. So it would seem that section 6.5 does 
> not describe a
> mechanism for preventing these collisions, it only provides a 
> possibility
> for
> programs to use the communication of locktokens as sync points for
> concurrent
> activities. It seems it is still the applications' responsibility to
> coordinate
> their updates appropriately through some out-of-band activity 
> like monitors,
> semaphores, etc. Am I missing something?
> 

To reiterate, program B could have discovered the lock token without having
to first check with program A by examining the owner element and checking
for any unique info that had been previously agreed upon. Once the ACL
standard is completed it will also be possible to include unique principal
identifiers.

In answer to your question, the scenario we are trying to prevent is not the
one you identify. If two programs both have the lock token and have been
authorized by the user to use the lock token then they are free to run rough
shod over each other. It is up to the user to make sure that they don't give
two seperate applications the ability to simultaneously access a locked
resource. For example, imagine you are editing a file in your favorite
editor and so have locked the file. You then go to the command prompt and
order that the file you are editing be moved. The move command will return
an error since it doesn't have the lock token. However the move program may
be smart enough to to do a lockdiscovery check, examine the owner element,
realize that you are the one who locked the file and offer to move the file
for you anyway. However it will first warn you that it is about to move a
file that another program has locked. If you still choose to allow the move
then you must also live with the consequences.

Thus the purpose of requiring the inclusion of the lock token is strictly to
prevent the scenario described in section 6.5.

> Section 6.5 says "... a lock token MUST be submitted by an authorized
> principal
> in the If header for all locked resources that a method may 
> interact with or
> the method MUST fail." Should this have been "... all locked 
> resources that
> a
> method may modify or the method MUST fail"? The example 
> follows this rule as
> the lock token destination is the only one required for the 
> COPY method. If
> this is the case, what about resource that are indirectly 
> modified by a
> method?
> Do their lock tokens have to be provided too? For example, consider a
> collection that is not depth locked, but contains a resource 
> that has an
> exclusive lock. Deleting the collection causes the locked 
> resource contained
> in
> it to be modified. Does the DELETE method have to have an If header
> containing
> the locked resource as well as the collection?
> 

"...for all locked resources that a method may interact with..." If you are
deleting a collection which contains a locked resource then obviously the
method effects that resource and so its lock token must be included.

> Section 6.6 says "A MOVE MUST NOT move the write lock with 
> the resource...".
> But it doesn't say what happens if this is attempted. Does 
> the move fail on
> this resource, or does the move occur and the lock is 
> removed? I assume the
> move fails on this resource but continues to move as many resources as
> possible. So for example, if a user attempts to move a 
> collection that is
> unlocked, but contains a resource locked by another user, the 
> collection is
> moved, but not the locked resource. What if the resource is 
> locked by the
> user
> doing the move? Is the resource moved in this case? If so, is the lock
> retained? It would be surprising if a user lost his locks 
> when moving a
> collection.
> 

All locks are lost when moving ANY resource, collection or not. The
specification does not prevent success when moving a locked resource however
any success will mean that the lock was lost.


> Section 7.10.7, What status code should be returned on an 
> attempt to refresh
> a
> lock on an unlocked resource? Precondition failed? Method Failure?
> Unauthorized? Seems like there might need to be a Not Locked 
> status code.
> Same
> question for attempting to unlock a resource that is not locked. As
> specified,
> Precondition failed will be returned as the locktoken in the 
> request cannot
> match any state of an unlocked resource. But this wouldn't be very
> descriptive.
> 

The response would be precondition failed in both cases and in both cases
the reason would be the If header. I agree that this isn't particular
pretty. It is my opinion that HTTP has a fairly serious problem when it
comes to response codes. I know that the HTTP-EXT working group is sniffing
around that problem and is considering making some recommendations on how to
improve matters.

> Again,  thanks for the help, and sorry about the long message.
> 
> 
>

Always happy to be of service,

		Yaron7

Received on Thursday, 9 July 1998 19:25:05 UTC