Re: Bindings and permissions

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.

Cullen


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).
> 
> Cheers, 
> Geoff 
> 
> 
> 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?
>> > 
>> > Lisa
>> > 
>> > 
>