Re: SLAPD: Should access checks take place before filter matching?

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 08:58 AM 6/21/2001, Simon Spero wrote:
>During the course of testing some other stuff I noticed that several functions in filter_entry check acl info before they test to see if the filter matches.

That's what the access control model calls for.

In our ACM, one must have search permission to evaluate a filter
and read permission to return the entry.  Search is dependent
on the filter and checked during filter evaluation.  Read
permissions apply only to matching entries.

>If there are large number of candidates being passed into the filter, they'll all be access checked, even if only a few of them are actual matches.

Yes.

>This makes searches much slower than they need to be, especially if the search involves a non-indexed field if any acls are defined. For example, a substring search on a field with no substring index, with about 12,000 entries and about 5 matches took 27 seconds with a single acl entry defined, but only 6 seconds with no acl set.

ACL can be expensive... especially regex based ACLs (and even more
so if the regex implementation is poor). 

>can anyone think of any reason why this would be a bad idea?

Different ACMs are not necessarily bad, they are just different.

>Now that I've got my working copy synced to HEAD  and reapplyed the kerberos_v4 sasl patches by hand, I'll make the changes to filter_entry.c and see how well they work.
>
>Simon
>p.s.
>It definitely seems that the access control code could benefit from some performance tuning; has anyone been working on this?

At present, no.