- From: Dan Brotsky <dbrotsky@Adobe.COM>
- Date: Thu, 28 Jun 2001 12:58:21 -0700
- 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: ><snip> > >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. dan -- 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