W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2001

RE: Webdav issue: UNLOCK_BY_NON_LOCK_OWNERS

From: Eric Sedlar <eric.sedlar@oracle.com>
Date: Wed, 15 Aug 2001 16:13:44 -0700
To: "Webdav WG" <w3c-dist-auth@w3c.org>
Message-ID: <NDBBKNOGFKEBJOOOIOOLCEOOCBAA.eric.sedlar@oracle.com>
The other issue, Geoff, is that people are using LOCK as a poor person's
CHECKOUT, also assuming that LOCK's won't timeout.  The RFC2518 revision
should clearly state that LOCKs aren't to be used for this purpose.

--Eric

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Wednesday, August 15, 2001 2:16 PM
> To: Webdav WG
> Subject: RE: Webdav issue: UNLOCK_BY_NON_LOCK_OWNERS
>
>
> Personally, I believe that any use case that assumes a long-lived
> lock is broken.  Those use cases should be handled by access control,
> not locks.  ACL's have no timeouts, and are principal based, which
> gives us a clean way of handling all the problems that have arisen
> when people have tried to use locks where they should be using ACL's.
> When you only use locks for short term reservations of a resource,
> all of these concerns about timeouts and locks being stolen evaporate.
>
> With the ACL draft in last call, we no longer have any
> reason to use locks as a poor man's ACL.
>
> Cheers,
> Geoff
>
>
> -----Original Message-----
> From: Jason Crawford [mailto:ccjason@us.ibm.com]
> Sent: Wednesday, August 15, 2001 3:03 PM
> To: Webdav WG
> Subject: Webdav issue: UNLOCK_BY_NON_LOCK_OWNERS
>
>
>
>
> I'm posting in part to get our subject line to actually describe
> what we're
> talking about.
>
> And to express an opinion and questions and observations...
>
> I think Shaun has some points.   Almost every explanation and discussion
> has focused on why a client should be able to deal with the lock going
> away.   Given that, Shaun's reaction seems reasonable.  We appear to be
> undermining some of the intent of the locks if that's all we say.   I can
> imagine a lot of other readers of 2518's next draft  scratching their head
> when we say people can just pick up the token and unlock the resource.
> Please let's not forget to include some mention of the fact that this
> capability is recommended to be under some sort of ACL control and it
> should not be possible to have one person unlock another person's
> resources
> willy-nilly and that it's not even required to support it.
>
> Note: I don't think 2518 actually requires servers to reveal the
> lock token
> in a the lock-discovery property.  Do we care?
>
> I would feel a lot better about all this if we had a good
> explanation about
> strategies to deal with lock timeouts.  How long should a client request
> the time out to be in various scenarios?  What pitfalls are there?   What
> solutions are there?   What ACL strategies would work best?  What refresh
> strategies?
>
> For example, I take out the lock.  I think I'll only need it for an hour.
> But I have to run home and the lock times out.   How must the client and
> server and human behave to handle that?  Should the client have
> requested a
> long timeout even though it didn't expect to need that much time?
>
> I want to lock a file, grab it, give it to a non-webDAV enabled friend to
> edit.  Then put it back on the server in a day or week or year.  What if I
> over estimate or underestimate the time needed?  What if a reboot is
> needed?  Or we forget that we did all this or I leave the company and the
> company needs to get the friend's change in there.   What is the best way
> to deal with these situations?  Long timeouts?  Frequest
> refreshs?  Exposed
> tokens in GUI's?  Lock stealing clients?  Lock stealing only of your own
> lock?  Clients that store tokens persistantly?  Servers that only expose
> tokens to certain principals?  Calls to the administrator?  ACL
> strategies?
>
> How do these strategies vary in different environments?   At the
> NSA?  In a
> classroom?  Often workign offline? Simply on localhost?
>
> I'm not sure if this could go in to the draft, but perhaps we
> could provide
> a checklist for client (and server?) implementations and server
> administrators to make sure they can handle situations like these.    Or
> perhaps we could discover that we only need a narrow set of optional
> behaviors to chose from.
>
> J.
>
> ------------------------------------------
> Phone: 914-784-7569,   ccjason@us.ibm.com
>
>
Received on Wednesday, 15 August 2001 19:09:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:56 GMT