browse permission in the ACM

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

All,

The following is a proposal to tweak the current browse permission in
the ACM.
The current usage of the "b" permission in the ACM is really just a read
level permission on candidate entries. From section 5.2:

" 1.  permission "b" to the entry candidateDN

      If this permission is not granted then the dn
      candidateDN MUST NOT be returned nor any attribute
      type nor attribute value from this entry.

      If this permission is granted then the dn candidateDN
      MAY be returned.
"

Some people felt that it would be better to have it behave more like
it's name suggests...which is that you would require this permission to
be able to have a search request return __non-base__ entries to you
during a search.  The spirit of this idea is something like "Hang on,
subtree and onelevel searches are really powerful, there should be a
way continue to grant read access to entries, but to limit the power of
these search options".

One way to do this is to refine "b" into two permissions 'new "b"' and
"v". 
The 'new "b"' still stands for browse and you will need this to see
non-base entries.   At a stretch the "v" stands for "vertex" as you need
this to see the base entry (the vertex) of a search.  (From now on "b"
means 'new "b"'.) To minimize the
number of combinations we also allow the base element to be seen if "b"
permission is assigned to it.  So, the new text I am proposing for this
would be:


" 1.  permission "v" or "b" to the entry candidateDN, if the entry is
the
     base of the search operation.
     permission "b" to the entry if the entry is not the base of the
search.

     If these conditions are not satisfied then the dn
     candidateDN MUST NOT be returned nor any attribute
     type nor attribute value from this entry.

     If this permission is granted then the dn candidateDN
     MAY be returned."

Note 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. 
We could specify such behaviour but I believe most LDAP implementations
have an "optimistic" approach to searching for entries ie. I may be
denied access to this entry, but there may be other entries to which I
do have access, so keep searching.

Note also that if you only ever use "b", it will behave just like a read
level permission on the entry--we provide the "v" refinement for those
users that might want to limit "browsability" of their DIT.

An example.  Suppose that some given user has all rights on all
these subtrees, the only difference being in allocation of the "b" and
"v" rights which are shown in brackets, after the RDN of the entry.

        ou=sun.com(b)
        |
        |------------------------------------------------
        |                       |                       |
        ou=sortOfBrowsable()    ou=notBrowsable(v)      ou=Browsable(b)
        |                       |                       |
        ou=level1(v)            ou=level1(v)            ou=level1(b)
        |                       |                       |
        ou=level2(b)            ou=level2(v)            ou=level2(b)


Eg 1: If he does a search like this:

        baseEntry: ou=sortOfBrowsable,o=sun.com
        filter: ou=*
        scope: subtree

He will get back the following entry:

        ou=level2,ou=sortOfBrowsable,ou=sun.com (has "b" on this)

-----

Eg 2: Then, if he does a search like this:

        baseEntry: ou=sortOfBrowsable,o=sun.com
        filter: ou=*
        scope: base

He will get back no entries (neither "v" nor "b" on the base).

-----

Eg 3: If he does a search like this:

        baseEntry: ou=notBrowsable,ou=sun.com
        filter: ou=*
        scope: subtree

He will get back the following entry:

        ou=notBrowsable,ou=sun.com (has "v" and it's the base)

-----


Eg 4: If he does a search like this:

        baseEntry: ou=notBrowsable,ou=sun.com
        filter: ou=*
        scope: base

He will get back the following entry:

        ou=notBrowsable,ou=sun.com (has "v" and it's the base)

-----


Eg 5: Then, if he does a search like this:

        baseEntry: ou=Browsable,ou=sun.com
        filter: ou=*
        scope: subtree

He will get back the following entries:
        ou=Browsable,ou=sun.com	(has "b")
        ou=level1,ou=Browsable,ou=sun.com (has "b")
        ou=level2,ou=Browsable,ou=sun.com (has "b")

-----


Eg 6: Then, if he does a search like this:

        baseEntry: ou=Browsable,ou=sun.com
        filter: ou=*
        scope: base

He will get back the following entries:
        ou=Browsable,ou=sun.com	(has "b")

-----


Eg 7: Then, if he does a search like this:

        baseEntry: ou=sun.com
        filter: ou=*
        scope: onelevel

He will get back the following entries:
        ou=Browsable,ou=sun.com	(has "b")

-----

Any comments on this modification ?

Rob.