Subject: Re: RFC-2518 LOCK-TOKEN: header

From: [email-masked]
Date: Thu, 27 Jan 2000 09:49:15 -0500

<geoff>
In particular, for merge avoidance, a lock token is required, and
which principal is issuing the request is irrelevant.  On the other
hand, for authenticated access control, the principal is required, and
a "lock-token" is irrelevant.  Thus all the confusion in the working
group about when/where a principal is required and when/where a lock
token is required.

Furthermore, for merge avoidance, you want to protect the URL, because
the URL is what the client is holding as the "key" to identify the
resource being authored.  On the other hand, for authenticated access
control, it is the *resource* that is being controlled, not the URL.
Thus all the confusion in the working group about whether a resource
is being protected or whether a URL is being protected.

So whatever was intended by WebDAV locks, the protocol that is
specified in rfc2518 does a fine job of preventing merge conflicts
for cooperating clients, and is totally inadequate for providing
authenticated access control.  So I propose that anyone that cares
about authenticated access control become active in the WebDAV ACL
specification effort, and just use WebDAV locks for what they can
do, namely prevent merge conflicts for cooperating clients.
</geoff>
<jra>
OK. Now I see what you're getting at. I didn't understand you were
proposing something that isn't in RFC2518 - lock tokens to prevent merge
conflicts for COOPERATING clints. (I know you said it a number of times, I
just kept interperting it from the point of view of the existing spec.)
This is an interesting approach, and one that could be more acceptable if
we had ACLs. But what does it hurt to require the lock token/authorization
pair? Especially in the case of shared locks? Wouldn't this allow the
server to "help" the clients cooperate? Isn't this the more traditional
notion of locking?
</jra>

---

From: [email-masked]
Date: Thu, 27 Jan 2000 17:57:03 -0500

<jra>
<jlc>
I agree with Jim's hint here.  The authentication is a good idea... as is
having the server enforce it.

As for merge conflicts, also having a revision ID/Lastmod and resource ID
and a header
line to verify these is a good idea.  But also having the server enforce
tokens and authentication as mentioned above seems like a good idea if
there
exist clients that aren't so careful about avoiding conflicts.

As stated a few months ago, I think server administrators/authors should
consider
their own security and issues when deciding if resources on their site
reveal
the lock-discovery property.  If some clients are stealing tokens and this
is
resulting in trouble, the servers should not reveal lock tokens via
lock-discovery. 2518 allows them to determine their own policy.

As for the need to peak at ld to find a lock token if one (client) has
misplaced their's...
the server administrator needs to weigh this possibility against the
possibility
of token stealing.  That being said, the client can't count on that
property even
existing.  Or that it's absense means there are no locks on a given
resource.

BTW, was there some issue in this thread that needs to go on the issues
list?
</jlc>

---

From: [email-masked]
Date: Thu, 27 Jan 2000 18:04:55 -0500

Jason,
If authentication+lock token is required, users can't "steal" other user's
lock tokens. This seems like a reasonable approach.

From: Jason Crawford on 01/27/2000 05:57 PM

To:   Jim Amsden/Raleigh/IBM@IBMUS
cc:   [email-masked]

Subject:  Re: RFC-2518 LOCK-TOKEN: header  (Document link: Jim Amsden)

<jra>

---

From: [email-masked]
Date: Sat, 29 Jan 2000 18:14:07 -0500

The current locking semantics allow multiple clients operating under the
same principal the flexibility of using the same lock tokens. This assumes
a single principal is more aware of their concurrent clients than say a
distributed work group. It does not however allow any other principal to
reuse the lock tokens. So although I agree with Geoff that locking and
access control are orthogonal issues, requiring principal+lock token is
useful, and not at odds with access control. Locks are an access control
mechanism no matter how one looks at them. They temporarily remove write
access to anyone not owning the lock. This seems quite reasonable and
doesn't necessarily have anything to do with ACLs. I guess I fail to see
the confusion.

Recall that the source of this issue is that the DAV:activelock element
does not contain the principal owning the lock. So there is no way for a
user to obtain the lock tokens they own through the DAV:lockdiscovery
property . I think this needs to be fixed. Otherwise, the semantics of
locking, with respect to  what is submitted for access, seem fine.

---

From: [email-masked]
Date: Mon, 31 Jan 2000 13:30:22 -0500

I agree with everything Geoff says, but I still think lock-tokens alone
aren't enough. Geoff says lock-tokens should be associated with clients.
But the only way this can be done is if clients don't reuse some other
client's lock token, or arbitrarily unlock them and get their own lock
token. If all clients were well-behaved and only:
    - used lock tokens the obtained from LOCK to update resources
    - except on rare and well coordincate instances, only unlock resources
they locked
    - never used shared locks
then this would work. Do we want locks to be purly advisory like this? I
would be willing to consider it. I've just been working on the assumption
that we wanted the server to do more.

But I still think there is a problem. In Geoff's scheme, lock-tokens are
now associated (essentially and by convention) with the client that took
out the lock. But there's no way in HTTP for the client to identify itself,
and therefore no way for the server to remember what client took out the
lock. That's why the server can't ensure only the client that got the lock
can update the resource, not just any client that might have the lock
token. So again, there's no way for the client to determine what lock
tokens it took out (i.e., owns) through a DAV:lockdiscovery. We're back to
having clients have to persist their lock tokens someplace else. I was
hoping to avoid this by at least using a DAV:principal in the
DAV:activelock to find the locks a particular principal owns.

"Geoffrey M. Clemm" <[email-masked]>@w3.org on 01/31/2000
10:37:24 AM

Sent by:  [email-masked]

To:   [email-masked]
cc:

Subject:  Re: RFC-2518 LOCK-TOKEN: header

   From: [email-masked]

   <geoff>
   ... if clients aren't going to restrict themselves to using
   the lock tokens that they created via LOCK, but will grab any
   lock-token that was created by their principal, then there is no
   reason to have the complexity of lock-tokens in the protocol.
   </geoff>

   <jra>
   We're getting there. The reason for associating the lock token with a
   principal is to give that principal the flexibility of running
concurrent
   clients that may update the same resource.

A principal can run concurrent clients that may update the same resource,
whether or not a lock token is associated with a principal.

   Since not all these clients
   actually locked the resource but got the lock token some other way, they
   are aware that there might be other clients that have the same lock
token
   and can warn the principal before using the lock token to update a
locked
   resource.

So every time such a client does a PUT/PROPPATCH to a "locked" resource,
it pops up a warning message saying "this might overwrite updates pending
in other clients working on your behalf, but I have no idea whether it
does or not because we use each others' lock tokens".  This is not a
behavior for which I would deliberately design a protocol.

Alternatively, the clients could be written to first UNLOCK a resource that
was locked by some other client, and then that other client (whether it
belonged to you or some other principal) would know this has occurred as
soon as it tries to make its next update, and could then notify that other
client's user that a merge conflict has occurred because someone
UNLOCK'ed your lock.

   ...
   3. Multiple clients run by the same principal would have to get there
own
   possibly exclusive write locks which would limit data availability by a
   single principal who likely knows what they are doing at the moment, and
if
   it is safe to proceed with an update. For example, the principal may be
   running many concurrent clients, but only one of them is active at a
time.
   The others are all waiting for input.

As a side note, "shared locks" are just, well, to be blunt, silly.
RFC2518 says you can take out a shared lock if you are a "principal
with appropriate access".  But if you are a principal with appropriate
access, you should just UNLOCK the resource and take out your own
exclusive lock on it.  This gives you all the benefits of "shared
locks", without losing the overwrite protection of exclusive locks.
Perhaps "silly" is a bit harsh ... or perhaps it is not harsh enough (:-).

Now as for the limiting data availability, how does the need to first
UNLOCK a locked-by-another client resource limit data availability?
Your client confirms (by asking you) that you really want to "steal" the
resource from another client (using the DAV:owner field to give a more
informative message), then UNLOCKs the resource, and then LOCKs
the resource to get its own locktoken.

I believe that you are try to get ACL behavior out of locktokens ...
I'd prefer to use ACL's to get ACL behavior (:-).  An ACL lets
you control which principals have write access to a resource (to prevent
damage from "hostile" principals), while locktokens lets cooperating
clients avoid merge conflicts.  An ACL is resource based and associated
with principals; a locktoken is URL-based and associated with clients.

   So I think associating the lock token with a principal is a reasonable
and
   useful compromise. It doesn't give absolute and complete overwrite
   protection for multiple current clients run by the same principal, but
it
   does guarantee overwrite protection between principals.

Associating a lock token with a principal is both too strong (it prevents
another principal with the same or higher access rights from authoring
that resource) and is too weak (it doesn't help avoid merge conflicts
between clients acting on behalf of the same client).

If this approach were consistent with our future direction (associating
ACL's with resources), I'd be more willing to accept it, but it isn't.
Requiring that only a principal that issued a LOCK can cancel that LOCK
will conflict with any attempts to allow a wider "trust" group for
that operation.

   Note that GULP R8 is consistent with associating principals with lock
   tokens.

Yes, that has been fixed (:-).  All mention of a "principal" has been
removed from R8.

Cheers,
Geoff