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

RE: PATCH: cache_groupacl {on|off}



--On Saturday, October 18, 2003 10:09 PM -0700 Howard Chu <hyc@highlandsun.com> 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.)

Hm... But in my experience of using static groups so far here at Stanford, is that the membership of a static group is not cached right now. I routinely add new members to static groups, and they have access from that point on. Or are you saying, a routine should be added to cache the membership, that only re-evaluates it when the modifyTimeStamp has changed?

Also, if this route is going to be explored, why limit it to groups? If the entry has changed since the server started, re-evaluate the ACL's. That would certainly drop the "restart slapd to re-evauluate your ACL's" bit. I think that could be problematic at sites where changes to accessing entities (human or otherwise) are made frequently.

As for the ACL's changing out from under a given bind, I don't like that idea, either... I think the environment of any given bind should stay consistent through it getting closed.

--Quanah

--
Quanah Gibson-Mount
Principal Software Developer
ITSS/TSS/Computing Systems
ITSS/TSS/Infrastructure Operations
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html