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

[George_Robert_Blakley_III@tivoli.com]

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.