[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: PATCH: cache_groupacl {on|off}

On Sat, 2003-10-18 at 23:09, Howard Chu wrote:
> I can understand your motivation, but I'm not too keen on this solution. For
> static groups we could add a timestamp to the cached result. Assuming the
> group is already in the backend's entry cache, the biggest cost is evaluating
> the list of members. It would be pretty cheap to examine the entry's
> modifyTimeStamp and determine whether a walk thru the member list is really
> needed or not. (For dynamic groups we can use the timestamp of the bound
> user's entry in the same way.)

This is why I made it configurable, and default to the original

As for the rest of your points - all valid, of course.  But it's
important to note that a better model might be to re-evaluate the group
memberships using a conditional akin to this one:

if ( ( groupEntry->timestamp != last_eval_timestamp ) &&
     ( operation->id != last_eval_operation_id ) )
	eval_group_permissions( groupEntry, binddn );

That way, we can continue to provide the results for a long search even
if the permissions change midway through the search.

Access will be denied AFTER the search is completed, because that's what
the new access rights (which should at that point be re-evaluated if
necessary) say should happen.

This allows "atomic" ('scuse the ill-chosen term :) ) evaluation of the
access rights: on a per-operation basis.

It also allows runtime permissions to behave more like they do on
databases - for example - where your permissions for a particular
operation reflect what you're allowed to do at the time you start the

I like this idea better than my previous one, and the current
always-cache-per-connection model.

But - alas - I'm not knowledgeable enough (yet :) ) to implement this.

What do you guys think?


* Diego Rivera                                            *
*                                                         *
* "The Disease: Windows, the cure: Linux"                 *
*                                                         *
* E-mail: lrivera<AT>racsa<DOT>co<DOT>cr                  *
* Replace: <AT>='@', <DOT>='.'                            *
*                                                         *
* GPG: BE59 5469 C696 C80D FF5C  5926 0B36 F8FF DA98 62AD *
* GPG Public Key avaliable at: http://pgp.mit.edu         *

Attachment: signature.asc
Description: This is a digitally signed message part