protecting dns in the ACM

[robert byrne <robert.byrne@Sun.COM>]

Rick raised a point about protecting dns in a recent mail:

> And one other vaguely related question that came to mind after reading
> Rob's email.  He notes that "... the absence of a "v" or "b" permission
> at any point does not abort the search operation as a whole or even on
> a particular subtree."
> 
> I have been assuming (and this seemed like a good time to check) that
> absence of a "t" permission DOES abort the search operation on a
> particular subtree, since returning the DN of any object further down
> in the tree would require that the DN of the object without "t"
> permission be returned.  Is that the generally accepted view?
> 

To show this problem here's a little tree where (all) means I have all
rights, (none) means I have no rights on that entry:

	o=sun.com (all)
	|
	ou=eng	(none)
	|
	cn=rob	(all)

Now, currently, if I do a subtree search with base o=sun.com then I will
get two entries: o=sun.com and cn=rob,ou=eng,o=sun.com.  The problem is
I am returned information about the ou=eng,o=sun.com entry, via the
entry cn=rob,ou=eng,o=sun.com, although in fact I have zero rights on
the ou=eng,o=sun.com entry.

I guess the consistent way to fix this would be to require that before
returning the dn of an entry, A say, I also need the rights to see the
naming attribute of each entry in the tree above A.  So, in the example,
before returning cn=rob,ou=eng,o=sun.com I should check I have rights to
see ou in ou=eng,o=sun.com and o in o=sun.com.  This has the advantage
of being really consistent, it has the disadvantage that when I want to
see a given entry, I need to evaluate not just my rights on _that_
entry, but on on all the ancestors of that entry.  My suspision is that
most implementors would prefer this inconsistency to the cost of
checking this extra dependency.  For example, alot of directory
implementaions use indexing based loosely on the search filter to
generate candidate lists of entries to return--in such a scheme you will
not "naturally" visit all the ancestors of an entry, so I think the
"abort subtree" approach would not naturally fit those implementations.

So I think we have a consistency/performance trade off and this is why I
am currently not in favour of specifying an "abort subtree" type
behaviour...but if anyone else can see an efficient way of fixing the
consistency problem...

Rob.