Re: Bind and permissions

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

On Tue, 05 Jul 2005 00:26:54 -0700, Julian Reschke <julian.reschke@gmx.de>  
wrote:

> 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



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

Received on Tuesday, 5 July 2005 16:05:32 UTC