search permission in the ACM

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

All,

The permission you require on an attribute in order to use it in a
search filter currently is quoted below from section 5.2.  I would like
to change these requirements as follows:

1. change "s" so that if you have "s" on an attribute you have the right
to use it in _any_ search filter.
2. drop the "r" requirement entirely.
3. add a new permission "p" to cover the case where you just want to
grant presence test ability to an attribute.

My idea is just to avoid overloading "r"--ie. with this approach only
the "s" and "p" permissions would be involved in checking access control
to filters and "r" would be just for testing for read permission on the
attribute.  Apart from that the idea is similar: "s" grants the right to
use the attribute in any search filter while "p" is reserved for those
attributes to which you just want to grant presence test rights.  The
motivation for the "p" permisison is that if you have full filter rights
on an attribute then in some cases that could be operationally the same
as having read permissiion ie. you could quickly determine the attribute
value, and this may not be desirable.  For example, if the type of the
attribute was integer then with full filter permissions you could
quickly determine the value by doing a sequence of binary chop style
searches using ">" and "<".  Whereas, with just the presence test
ability, you would not have right to do those kind of searches, but you
would be able to test for the presence of the attribute.

Rob.

"2.  permission "s" to each attribute appearing in a search
      filter presence test during the evaluation of the
      search filter.  permission "r" and "s" to each
      attribute appearing in non-presence tests (see
      rfc1960, section 3: equalityMatch, substrings,
      greaterOrEquial, lessOrEqual, present, approxMatch,
      extensibleMatch) during the evaluation of the search
      filter.

      The above statement covers the case where the
      attributes are being evaluated as part of an
      extensibleMatch (RFC 2251 section 4.5.1) which appears
      in the filter.  In the case where the dnAttributes
      field of the extensibleMatch is true then we do not
      require any access checks to the attributes of the dn
      candidateDN as access to these is taken to be granted
      by the "b" permission, which has already been required
      above.

      If there is an attribute in a filter element to which
      the required permission is not granted then that
      filter element evaluates to "Undefined" of the three-
      valued-logic of X.511(93)."