Subject: RE: rfc2818 issue: UNLOCK_BY_NON_LOCK_OWNER

From: "Clemm, Geoff" <[email-masked]>
Date: Sun, 15 Jul 2001 07:22:15 -0400

I agree with Lisa that who can unlock a resource should be an
access control issue (exposable and controllable through the
access control protocol), and not something hard-wired into the
locking protocol.

I would extend this statement to say that this applies to any
use of a lock token on a resource, not just to who can use it
for UNLOCK.  So I would remove the "only by owner" language in
2518, which states that only the "owner" of a lock token can use it,
and replace it with "only a client with sufficient privileges".

Cheers,
Geoff

-----Original Message-----
From: Lisa Dusseault [mailto:[email-masked]]
Sent: Friday, July 13, 2001 6:07 PM
To: Jason Crawford; WebDAV
Subject: RE: rfc2818 issue: UNLOCK_BY_NON_LOCK_OWNER

Well, since I was the one who brought it up, here are my thoughts.

It seems not entirely unreasonable to have a system where the resource owner
can remove locks on their resource, even locks that the resource owner did
not create.  With ACLs in the mix, this makes even more sense.  After all,
if somebody has the ability to grant permission whether or not somebody can
lock a resource, they might as well have the ability to remove locks.

To the client that had their lock disappear, it's just like the lock
expired.  They can try to get another.  There may be changes they may have
to merge.

Now it doesn't have to be the resource owner that can do this.  It can be
entirely up to the implementation or the lock policy.  This is made nicely
possible in WebDAV because it makes the locktoken available for anybody to
use to try to UNLOCK the resource.  It just leaves it up to the
implementation whether or not to allow this to succeed.

lisa

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Jason Crawford
> Sent: Wednesday, July 11, 2001 10:41 PM
> To: WebDAV
> Subject: rfc2818 issue: UNLOCK_BY_NON_LOCK_OWNER
>
>
>
>
> Okay All:   I'm going through the issue list and am going to try
> to present
> two issues per week for a while.  The first one up tonight is...
>
> ------------------------------------------------------------------
> UNLOCK_BY_NON_LOCK_OWNER
>
> At present, the specification is not explicit about who might be
> capable of
> grabbing a lock token via lock discovery and the submitting it in UNLOCK
> (and/or for a subsequent write operation). It is OK for the resource owner
> to grab the lock token and do UNLOCK/write? Is it OK to have a "grab lock
> token" privilege that can be assigned to anyone?
> -----------------------------------------------------------------
>
> The issues list notes that this was raised by Lisa Dusseault in private
> email (I believe to Jim).  I also believe we discussed what is largely the
> same issue briefly recently.  I think you can find them in reverse
> chronological order at...
>
> http://lists.w3.org/Archives/Public/w3c-dist-auth/2001AprJun/index
.html#351
in various threads mentioning lock discovery in their subject.

I'll step back and let someone else kick of the discussion on this.

J.

------------------------------------------
Phone: 914-784-7569,   [email-masked]

---

From: "Tim Ellison" <[email-masked]>
Date: Mon, 16 Jul 2001 10:38:10 +0100

I agree with Lisa.

Lisa wrote:
> It seems not entirely unreasonable to have a system
> where the resource owner can remove locks on their
> resource, even locks that the resource owner did not
> create.  With ACLs in the mix, this makes even more
> sense.  After all, if somebody has the ability to
> grant permission whether or not somebody can lock a
> resource, they might as well have the ability to remove
> locks.
>
> To the client that had their lock disappear, it's just
> like the lock expired.  They can try to get another.
> There may be changes they may have to merge.
>
> Now it doesn't have to be the resource owner that can
> do this.  It can be entirely up to the implementation
> or the lock policy.  This is made nicely possible in
> WebDAV because it makes the locktoken available for
> anybody to use to try to UNLOCK the resource.  It just
> leaves it up to the implementation whether or not to
> allow this to succeed.

---

From: "Jason Crawford" <[email-masked]>
Date: Mon, 23 Jul 2001 13:32:01 -0400

<<
Lisa, Geoff and Tim have all agreed along these lines and noone has
disagreed.  My next question is...  What should 2518 say then?  Nothing and
leave a void?  Explicitly delegate to the ACL spec?

The only suggestion so far is...

<<

Is this the change to 2518 that we want?  Any other suggestions?  Let's
hear from you?

J.