Subject: Bind and permissions

From: "Lisa Dusseault" <[email-masked]>
Date: Mon, 04 Jul 2005 21:22:54 -0700

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?

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".

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.

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.

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Tue, 05 Jul 2005 09:26:54 +0200

> 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."

> we do so. Furthermore, I would argue that the right answer is

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

> 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)."

> I'd like to get a sense of what people feel the current state

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

Best regards, Julian

---

From: "Lisa Dusseault" <[email-masked]>
Date: Tue, 05 Jul 2005 09:05:22 -0700

My bad -- I don't know how I forgot that section 9 on relationship to ACL  
had been added to the Bind spec.  That did make things a lot better.

I'm still concerned that the combination of ACL and BIND can't be  
implemented interoperably, but I'm starting to agree with Julian that the  
problem is in the ACL spec rather than the BIND spec.

Are implementors agreed that when a resource is bound into a new  
collection, that no new ACL initialization can be done?  So if I bind a  
resource into a collection that I share with Jim, and this sharing is  
handled by initialization, the server MUST NOT alter the ACL such that the  
resource is now readable by Jim?

thanks,

Lisa

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

---

From: Julian Reschke <[email-masked]>
Date: Tue, 05 Jul 2005 19:24:20 +0200

Lisa Dusseault wrote:
> 
> My bad -- I don't know how I forgot that section 9 on relationship to 
> ACL  had been added to the Bind spec.  That did make things a lot better.
> 
> implemented interoperably, but I'm starting to agree with Julian that 
> the  problem is in the ACL spec rather than the BIND spec.

I didn't say that there is a problem with the ACL spec. What the ACL 
spec says about namespace operations probably is the consensus of the 
WebDAV working group back then; so if it makes a special statement about 
namespace operations, it makes that on purpose.

> handled by initialization, the server MUST NOT alter the ACL such that 
> the  resource is now readable by Jim?

I think that would be a contradiction to what the combination of the 
specs currently say. Why would BIND have different constraints than MOVE?

Best regards, Julian