W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2005

Re: Bind and permissions

From: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 05 Jul 2005 09:26:54 +0200
Message-ID: <42CA363E.2010807@gmx.de>
To: Lisa Dusseault <lisa@osafoundation.org>
CC: Webdav WG <w3c-dist-auth@w3c.org>

Lisa Dusseault wrote:
> 
> This message attempts to explain my concern about the interaction of
> ACLs and bind. The basic question I have is this: if you have a
> resource with two bindings can different access control behavior
> be applied depending on which URL the resource is accessed through?

RFC3744, section 5 
(<http://greenbytes.de/tech/webdav/rfc3744.html#rfc.section.5>):

"Access control properties (especially DAV:acl and 
DAV:inherited-acl-set) are defined on the resource identified by the 
Request-URI of a PROPFIND request. A direct consequence is that if the 
resource is accessible via multiple URI, the value of access control 
properties is the same across these URI."

> It seems to me that there are three possible answers here:
> 
> (1) No.
> (2) Yes.
> (3) It's locally defined.
> 
> Others may feel differently, but my view based is that the current
> language in 2518, 3744, and draft-ietf-webdav-bind-11 doesn't
> provide a definitive answer, but that it's important that
> we do so. Furthermore, I would argue that the right answer is
> "No".

Yes, I feel differently. The answer clearly *is* "no".

> A related question is if you think the answer is "No", then what
> is the access control status of a resource that is bound into a
> collection with different ACL settings (incl. inheritance) than
> the collection the resource is already in.

Depends on the server. See RFC3744, section 7.3 
(<http://greenbytes.de/tech/webdav/rfc3744.html#rfc.section.7.3>):

"When a resource is moved from one location to another due to a MOVE 
request, the non-inherited and non-protected ACEs in the DAV:acl 
property of the resource MUST NOT be modified, or the MOVE request 
fails. Handling of inherited and protected ACEs is intentionally 
undefined to give server implementations flexibility in how they 
implement ACE inheritance and protection."

and BIND, section 9 
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-11.html#rfc.section.9>):

"BIND and REBIND behave the same as MOVE with respect to the DAV:acl 
property (see [RFC3744], section 7.3)."

> However, before making an extended argument on that point,
> I'd like to get a sense of what people feel the current state
> of affairs is.

My feeling is that there's absolutely no point in arguing this topic. 
The specs are very clear about this.

Best regards, Julian
Received on Tuesday, 5 July 2005 07:27:10 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:09 GMT