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

RE: Status code for creating lock-null resource

From: Dan Brotsky <dbrotsky@Adobe.COM>
Date: Thu, 28 Jun 2001 12:58:21 -0700
Message-Id: <p04330104b76129a4b123@[]>
To: "Lisa Dusseault" <lisa@xythos.com>
Cc: "Alan Kent" <ajk@mds.rmit.edu.au>, <w3c-dist-auth@w3.org>
At 9:36 AM -0700 6/28/01, Lisa Dusseault wrote:
>So let's imagine we could transform lock-null resources into locked empty
>resources -- the only requirement on the server would now be that the server
>would allow the creation of an empty resource through use of the LOCK
>request.  With a locked empty resource, it's a regular resource, it appears
>in listings, and it doesn't magically go away if no PUT request is received
>before UNLOCK.  Would this help us out?

I claim yes.  That's exactly what I'm proposing, and where I think 
Tim and Jim got to in their discussion earlier on this thread.

>A locked empty resource as I described would solve the PUT-control problem,
>but not the MKCOL problem, unless the server were required to be able to
>support MKCOL on a locked empty resource.

Which I think is reasonable, but I'm likely to be in the minority about this.

>   So if I have write and
>permissions access to a repository where other users have write and
>permissions access, I could create a directory called "lisa" - and there's a
>risk that somebody else can change permissions before I have a chance to.
>The malicious user could lock me out of my own directory.  On the other
>hand, presumably the malicious user could create a directory called "lisa"
>in the first place and not have to worry about waiting for me to create it.

I really don't think malicious users are the problem.  It's 
accidental collisions that are the problem: you want to make 
directory "lisa" because it's your name at the same time someone else 
wants to make file "lisa" because it's a picture of her niece Lisa. 
Accidental collisions are rare but a real pain if the underlying 
protocol allows races.

>Some servers will solve this problem by assigning special permissions to the
>creator of a resource, however I don't think we can rely on this being
>always the case. There are certainly use cases for other permissions models.
>We would want to think about whether it's valid for a server to grant
>permissions permission on newly created resources to principals that did not
>either create the new resource, or own the parent resource.

It's valid for servers to do whatever is appropriate for the 
application.  This gets back to the other example I raised in my 
message: workflow servers typically want to attribute workflow intent 
to file operations, so two PUTS are quite different than one, and 
LOCK / PUT means something quite different than PUT / LOCK.

I think that, without requiring servers to support "placeholder" 
resources of some kind, it's going to be hard to avoid races around 
LOCKING and creation.  I think that's why LNRs were introduced in the 
first place.  I simply think that the notion of placeholder was too 
restrictive, and the notion of a "placeholder that vanishes" was just 
ill-conceived.  Since HTTP already supports the notion of 
"placeholders" well with no-content resources, I think we can simply 
say that LOCKing an unmapped URI puts a locked no-content resource 
there, and it stays there until someone either says "here's content" 
with PUT or "actually it's a collection" with MKCOL.  If they really 
made a mistake they can say DELETE.

Daniel Brotsky, Adobe Systems
tel 408-536-4150, pager 877-704-4062
2-way pager email: <mailto:page-dbrotsky@adobe.com>
Received on Thursday, 28 June 2001 16:08:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:23 UTC