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

From: [email-masked]
Date: Thu, 4 Jan 2001 14:52:09 -0600

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.

[email-masked] on 12/14/2000 09:22:38 PM

Please respond to <[email-masked]>

To:   <[email-masked]>
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.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 06 Jan 2001 09:15:26 -0800

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