Re: ldap acl draft (06): browse needed ?

["Jim Sermersheim" <jimse@novell.com>]

I agree with Kurt's view. At a point in NDS's past, we had to abandon the hierarchical, or tree-walk type of searching that required the browse permission due to the scalability and performance constraints it imposed.

Jim

>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 1/6/01 10:15:26 AM >>>
Bob,

If I understand your suggestion properly, you wish to have a
mechanism where return entries is controlled by controls placed
upon 'intermediate' entries.  I define an intermediate entry
as any entry between the 'base' and matching entry excluding
both.

In implementations that I am familiar with, providing such
functionality would be extremely difficult as they use indexing
systems to locate matching entries and don't examine intermediate
entries (or ACLs upon intermediate entries) to determine whether
or not to returned matched entries.  Doing so would be require
significant redesign of such implementations.

I would suggest that any ACL feature which required servers relying
on the contents of intermediate entries be OPTIONAL.

Kurt

At 02:52 PM 1/4/01 -0600, George_Robert_Blakley_III@tivoli.com wrote:
>Rob,
>
>The intent of the "browse" permission is not to prevent discovery of DNs;
>that is what "returnDN" permission is for.
>
>"browse" is to take care of the case where there is a hierarchy of entries
>and:
>
>(1) A subject "S" has authority to perform some operation (say "read") on
>an entry (call it "E") which is not the root
>(2) "S" has no permission to read or otherwise do anything to some entry
>"I" which is on the path between the root and "E"
>(3) "S" does not know or does not wish to use the explicit name of entry
>"E"
>
>An example of this case is when a subject "Bob" has "read" access to a leaf
>entry but no access to any other entry,
>and does not know the name of any entry in the hierarchy.  Bob wishes to do
>a query on some attribute value.  This query
>matches an attribute of "E", and hence (since Bob has permission to read
>E), E should be returned in response to the
>query.
>
>However, if Bob tries to execute the search starting at the only point he
>knows about (the root), the query will fail, because
>he has no permission to "I" or any other entry on the path between the root
>and "E".
>
>This is exactly analogous to the use of the "x" mode bit in the UNIX
>filesystem to allow users to traverse directories into
>which they cannot write and from which they cannot read.
>
>--bob
>
>Bob Blakley
>Chief Scientist, Security
>Tivoli Systems, Inc.
>
>
>ietf-ldapext-request@netscape.com on 12/14/2000 09:22:38 PM
>
>Please respond to <rbyrne@bebop.France.Sun.COM>
>
>To:   <ietf-ldapext@netscape.com>
>cc:
>Subject:  ldap acl draft (06): browse needed ?
>
>
>
>
>The current acl draft proposes an entry level permission called "browseDN"
>(4.2.2).  The idea behind this permssion is to able to set a
>policy saying something like "you can see this entry if you name it
>explicitly as the base of a search, otherwise not".
>
>At Pittsburgh people seemed to like this permission and I agreed to do a
>proposal for this....however, relative
>to a single "read" level permission that ignores scoping it does complicate
>things.  The definition of the required permissions for
>search (5.2) already has to deal with a fair line up of other permssions
>(filter (presence and "the rest"), attribute level read, returnDN
>and discloseOnError).  While providing more permssions certainly increases
>the flexibility of the model,
>it also makes it harder to understand and administrate,  so my inclination
>is drop the browse permission in favour of a single "read"
>permission at the entry level.
>
>My question is do people feel strongly that the "browse" permission is
>required ?  If so, please propose a compelling scenario that
>really needs this granularity  of control of search permissions.  I will
>then include this as a motivating example and propose a way to include
>it in the required permssions for search.  Otherwise I intend to drop it
>for the 07 draft...
>
>Rob.