[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
search permission in the ACM
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)."