Re: Bindings and permissions

> I was thinking about the bindings and permissions stuff today.  I've 
> discussed it before but this may be a new take on the subject.  Recall 
> we don't really know what the behavior is with dynamically inherited 
> ACLs (when a parent's ACLs automatically apply to its child resources) 
> when some of those children are bindings to resources that also have 
> bindings.  Some of the possible solutions to this:

We don't know that because that's beyond the scope of RFC3744. As far as
I can tell, the only inheritance mentioned over there is when ACEs or
ACLs are explicitly inherited from another resource, identified by URL.
*That* model is compatible with multiple bindings, because the
inheritance chain still is well-defined.

> ...
> It seems to me clients have no way of knowing which solution the server 
> has chosen and behavior can be quite unpredictable.  Is there some way 
> to advertise the server's model? Are some of these choices forbidden?  
> Of those that aren't forbidden, is one of them recommended?
> 
> It would be extremely surprising if the 'bind' privilege grants 
> somebody the ability to make a new mapping of a resource into a new 
> directory, AND that a consequence of that 'bind' operation is to change 
> the permissions on the underlying resource -- without requiring 
> 'writeacl' privilege.  Since that's a possible security hole, what 
> should that be -- a MUST NOT?  A security consideration?
> ...

I'm really not sure what you're asking for. This seems to be about a
server implementing an ACL model that's not compatible with RFC3744. In
which case neither RFC3744 nor BIND can hep you predicting the server's
behavior.

I guess I'm missing something; but I dunno what. Please explain.

Best regards, Julian

Received on Thursday, 22 December 2005 13:24:04 UTC