Subject: Re: Bindings and permissions

From: Cullen Jennings <[email-masked]>
Date: Sat, 21 Jan 2006 13:32:34 -0800

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" <[email-masked]> 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
>> > 
>> > 
>

---

From: Geoffrey M Clemm <[email-masked]>
Date: Sat, 21 Jan 2006 16:50:19 -0500

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.

---

From: Lisa Dusseault <[email-masked]>
Date: Sat, 21 Jan 2006 16:09:12 -0800

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

---

From: Julian Reschke <[email-masked]>
Date: Sun, 22 Jan 2006 10:46:10 +0100

> any new issues in that regard.

I fully agree with Geoff here.

RFC3744 doesn't define how a server handles inherited ACLs (if the 
inheritance isn't made explicit by specifying the resource from which 
the ACLs are inherited, as per 
<http://greenbytes.de/tech/webdav/rfc3744.html#rfc.section.5.5.4> and 
<http://greenbytes.de/tech/webdav/rfc3744.html#rfc.section.5.7>).

Lisa's question seems to be: "how does a BIND+ACL server behave with 
dynamically inherited ACLs?", and the answer clearly is: "it's 
undefined, just like with an ACL server that does not support BIND".

Now I understand that someone who wants to implement both in one server 
will ask the WG for opinion anyway, and that's fine. But, again: this is 
about a restriction in the RFC3744 ACL model and really, really doesn't 
have anything to do with BIND.

Best regards, Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Sun, 22 Jan 2006 08:54:57 -0500

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

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 23 Jan 2006 09:36:42 -0800

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

---

From: Julian Reschke <[email-masked]>
Date: Mon, 23 Jan 2006 18:46:14 +0100

Lisa Dusseault wrote:
> supporting ACL that does dynamic inheritance, I figure that whether or 
> not ACL theoretically supports dynamic inheritance, in practice it does.

Then that server has chosen an ACL model that is undefined under RFC3744.

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

All of these are good questions, but I don't see how BIND can possibly 
answer that, when even the behavior for single bindings is not defined 
within any IETF spec.

Best regards, Julian