Kurt D. Zeilenga wrote:
I think the general assumption was that if the client
has some search permission (check by test_filter
prior to calling send_search_entry), it has read on
"entry". Now, with overlays and other things happening,
having send_search_result indicate whether or not an entry
was actually sent (or possibly the number of entries
sent?) would be a good idea.
Since send_search_entry() maintains the actual counter of number of
entries sent, and has access to the sizelimit in the operation
structure, it would make the most sense for it to do the test and return
a SIZELIMIT_EXCEEDED result to the caller when appropriate. Then no
callers (backends or overlays) need to worry about testing the limit,
they just need to handle the non-success return codes. (Which they do
already.)
At 03:14 PM 11/23/2005, Howard Chu wrote:
Eric Irrgang wrote:
I'm sorry if this has already been discussed, but I can't seem to find
such a thread in the archives...
With OL 2.2.29 it looks to me like the sizelimit specified by a client
search is evaluated after the ACLs on the server side, so that if a client
specifies a sizelimit of 10 and receives 8 results, it may be obvious that
2 entries matched the filter but failed the ACL check, disclosing perhaps
more information than the directory maintainers would like.
Is this expected/intended behavior?
It is the as-designed behavior. But you're right, the design is broken here.
Currently all sizelimit checking is done in the individual backends, while the
search ACLs are checked in the frontend. Checking in the backends means there's
a lot of redundant code; it should all be moved into the frontend.
Such a change would break the pagedResults implementation in back-bdb. But
that's probably OK, since the pagedResults feature properly belongs in the
frontend as well.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/