Re: Bindings and permissions

I guess our mis-alignment is partly based on whether ACL supports  
dynamic ACL inheritance.  Since I know of more than one server  
supporting ACL that does dynamic inheritance, I figure that whether  
or not ACL theoretically supports dynamic inheritance, in practice it  
does.

Still, I would argue that's irrelevant.  Doesn't a client have an  
expectation that when it does a BIND request
  - that the resource being bound doesn't become less accessible, or  
more accessible, as a result of the request; in other words that the  
BIND request has reasonably predictable side effects
     - regardless of whether the server supports ACL spec
     - regardless of whether the server supports dynamic inheritance,  
which as you say isn't really discoverable?

Lisa

On Jan 22, 2006, at 5:54 AM, Geoffrey M Clemm wrote:

>
> Perhaps if you could address the issues raised in my message
> (i.e., the ACL spec doesn't support dynamic ACL inheritance,
> your suggested changes mistakenly assume that the ACL spec
> does support dynamic ACL inheritance, and the issues of
> multiple inheritance occur whether or not you have multiple
> bindings to a resource and therefore is not
> a bind-specific issue), rather than just stating that you
> disagree and re-proposing your changes, we could have a
> more productive discussion.
>
> Cheers,
> Geoff
>
> Lisa Dusseault <lisa@osafoundation.org> wrote on 01/21/2006  
> 07:09:12 PM:
>
> > I fundamentally disagree that this situation isn't affected by the
> > Bind mechanics and can't be addressed at all in the Bind spec.  It's
> > pretty absolute of you to say that there is "nothing that can be
> > changed about the bind spec to address this issue" as I've suggested
> > some changes in the past.
> >
> > lisa
> >
> > On Jan 21, 2006, at 1:50 PM, Geoffrey M Clemm wrote:
> >
> >
> > The issues/questions raised by Lisa are not related to the bind  
> spec;
> > they are about dynamically inherited ACL's, which is not  
> something that
> > is currently modeled in the ACL spec.  So there is nothing that can
> > be changed about the bind spec to address this issue ... it is an  
> ACL
> > spec issue.  If the ACL spec were extended to model dynamically  
> inherited
> > ACL's, then it would need to deal with multiple parents, but that  
> is no
> > harder than dealing with the interaction of the ACL directly on a  
> resource
> > with the ACL's that it inherits, so multiple bindings does not  
> introduce
> > any new issues in that regard.
> >
> > Cheers,
> > Geoff
> >
> > Cullen wrote on 01/21/2006 04:32:34 PM:
> > > Hmm, some of this was before I was following webdav. It does not
> > > surprise me that the IESG said the some proposed ACL model was not
> > > simple enough to implement and requested changes. It would  
> surprise
> > > me greatly that they would be looking for something that was so
> > > simple that it was not capable of solving the problem.
> > >
> > > I suspect the guiding principle here should be as simple as  
> possible
> > > but no simpler. Something that does not explants how to deal with
> > > the situations that bind allows either mean that bind need to be
> > > changed to allow less situations or that the solution is not  
> complete.
> >
> > > On 12/16/05 6:29 PM, "Geoffrey M Clemm"  
> <geoffrey.clemm@us.ibm.com> wrote:
> > > There are ways to model this kind of thing, but the guidance we
> > > received for the ACL spec is that the resulting ACL model is too
> > > complicated, which is why we ended up with a much simpler model
> > > (that cannot model this kind of thing).  So I think the simple  
> answer
> > > is "no, there is no way for a client to find out about complex
> > > ACL situations such as the ones you describe" (unless the IESG
> > > changes its mind about how complex an ACL model is acceptable).
> >
> > > Lisa wrote on 12/16/2005 07:13:21 PM:
> > > > 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:
> > > >
> > > > 1.  Directory permissions are not dynamically applicable to  
> children or
> > > > at least to bindings.
> > > > 2.  You can't bind resources into directories that have  
> different ACLs
> > > > than where they're bound already - server returns 403 or  
> something
> > > > 3.  Permissions are path-dependent.
> > > > 4.  Not all bindings are first-class -- there's a "real name"  
> and then
> > > > there are aliases.  The collection containing the "real name"  
> is the
> > > > one that inherits permissions
> > > > 5.  There's some algorithm for "summing" or "intersecting" the
> > > > permissions according to the parents of all the bindings.
> > > >
> > > > There may be other possible models.
> > > >
> > > > 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?