Re: protecting dns in the ACM

[rvh@qsun.mt.att.com (Richard V Huber)]

The reason I thought that "abort subtree" was the expected behavior is
the wording of the definition of the "t" permission in Section 4.2.1:

  t returnDN

  If granted, allows the distinguished name of the entry to be
  disclosed in the operation result.

So if the requester does not have "t" permission for ou=eng in Rob's
example, I expected that neither "ou=eng, o=sun.com" nor "cn=rob,
ou=eng, o=sun.com" would be returned since both of them disclose the DN
"ou=eng, o=sun.com" in the result.

If the interpretation in Rob's email is the desired result, then I
think the definition of "t" permission needs to be clarified.  And is
"t" permission really useful if it is so easy to get around it?  It
would seem that "t" only protects the DN of a leaf node, not any
interior node.

I have a few other comments embedded in Rob's email below.

Rick Huber

: Sender: Robert.Byrne@Sun.COM
: From: robert byrne <robert.byrne@Sun.COM>
: To: ietf-ldapext@netscape.com
: Subject: protecting dns in the ACM
: 
: 
: 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.

The draft currently says (Section 5.2, note following discussion of the
"b" permission in search operations) that the "b" permission allows the
DN to be returned even if the requester does not have "r" permission
for the naming attributes.  Would this suggestion mean that the "DN"
entry-level permissions ("b", "t", etc.) go away and that we just
depend on the permissions that apply to the naming attributes of the
entry?  Or would "b" and "t" still have some purpose?

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

One cause of the inconsistency seems to be that we have entry-level
permissions that sometimes override attribute-level permissions for
naming attributes.  This may be a useful shorthand that makes
implementations easier.  But if we decide it is useful to have these
permissions we need to carefully define the interactions.

: Rob.