- From: Clemm, Geoff <gclemm@rational.com>
- Date: Thu, 6 Sep 2001 01:14:46 -0400
- To: Webdav WG <w3c-dist-auth@w3c.org>
I agree with Lisa's response, especially the fact that a client should never grab a lock token just because it is visible, and try to use it (whether or not you are the "owner" of that lock token). The only use of a lock token that has been "discovered" should be for an UNLOCK, after an explicit dialog with the user confirming that overriding the lock is what is wanted. As for discovering who is the lock owner, that is what the DAV:owner element in the lock discovery property is for. This information is to be displayed to the user (e.g. to indicate that the write failed because "a lock is held by xxx", or to ask "do you want to override the lock held by xxx"). Cheers, Geoff -----Original Message----- From: Lisa Dusseault [mailto:lisa@xythos.com] Sent: Wednesday, September 05, 2001 7:49 PM To: Daniel Brotsky; Webdav WG Subject: RE: Webdav issue: UNLOCK_BY_NON_LOCK_OWNERS > a. Of course servers may allow principals other than a lock owner to > unlock a resource: servers can do whatever they want with locks. The > question for the spec is: *how* do they allow this? I'd assumed this would be the same way any user does an UNLOCK. I don't think there's any need to define a new syntax (more on this later in the email). Xythos WFS supports UNLOCK by the resource owner as well as by the lock creator. The resource owner must do PROPFIND "DAV:lockdiscovery" first to find out what the lock token is, then remove it. > b. Of course if a server allows principals to do something, and the > server supports access control, then the allowance should be under > access control: it's only logical. The question for the spec is: > *how* is it under access control? Not everything that is allowed by WebDAV has its own privilege in DAV ACLs. Note particularly that the ability to LOCK the file isn't covered by its own privilege! A server might implement the privilege to blow away another's lock as part of the write-acl privilege. Of course, the ACL framework is flexible enough to allow servers to define sub-privileges. Eg 1: custom:lock, custom:delete and custom:write might be separate custom privileges that are covered under the framework of the DAV:write privilege. Eg 2: custom:unlock and custom:set-privilege might be custom privileges that are covered under the framework of the DAV:write-acl privilege. WFS has implemented unlock-by-non-lock-owners to be allowed only by the owner of the resource. I don't think this needs to be part of the ACL spec right now. An extension to the ACL spec might be useful, once ACL is done. > c. Of course there are tradeoffs around any authorization policy. > The question for the spec is: are there any *requirements* on servers > that choose one policy or the other? Yes. Xythos WFS requires the ability for a resource owner to remove a lock that was created by some other user. This must be accessible over WebDAV because resource owners don't have administrative access to the system. The primary reason this is a requirement is because resource owners have limited quotas. If they can't blow away a lock created by some other user, then they can't delete the resource and free up space when they reach their quota. Even on systems without quotas, the goal of minimizing administrative costs requires this feature. It's too costly for users to be phoning the support staff every time they need a lock removed for some "urgent" reason. > 2. As to a: I believe that using the exact same syntax for UNLOCK > regardless of whether you own the lock (or just have permission to > blow locks away) would be very error-prone. It would mean that > clients that routinely do lock discovery (rather than remembering > tokens) could easily blow away others' locks when they thought they > were just unlocking their own. Clients should NEVER EVER do this, regardless of whether the server supports this UNLOCK-by-non-lock-owner. That would mean that the client is relying on access control of the server to regulate whether or not it may blow away the lock. That fails in the simple case when the user has two software applications that both support DAV! If I'm using Windows Word with Web Folders to open and lock a file, then I start up Acrobat to see if I can view the same file I'm editing, it would be wrong for Acrobat to grab the lock and allow edits. That kind of unpredictability is unacceptable. > (Especially because the spec provides > no way to reliably determine who owns a lock.) This is a good point -- and this is already a failing of WebDAV, with or without UNLOCK_BY_NON_LOCK_OWNER. Clients that crash or miss the response from the server need to make sure that the lock is theirs before grabbing the lock token using PROPFIND. Can lockowner be used for this purpose? This should be a separate RFC2518 issue. How about "HOW_TO_IDENTIFY_LOCK_OWNER". > So I believe we need > some mechanism for saying, in an UNLOCK call, that I expect the lock > to be owned by someone else and I want to unlock it anyway. (And > this form would fail if I owned the lock.) If we solve the problem of telling what client created the lock, which I've pointed out we ought to solve anyway, we wouldn't have to add syntax to the UNLOCK call. > As you can see, I think we're a ways from an operable concensus > around this issue. I think there are a raft of important questions > that get opened by allowing explicit unlocking, I hope I've answered a few of those questions, although I agree a new RFC2518 issue must be raised (HOW_TO_IDENTIFY_LOCK_OWNER). If we solve that question, I don't see any further open issues that would prevent UNLOCK_BY_NON_LOCK_OWNER. Lisa
Received on Thursday, 6 September 2001 01:03:53 UTC