Ilja Booij <[EMAIL PROTECTED]> said: > On Wed, 22 Dec 2004 09:22:44 +0100, Hans Kristian Rosbach wrote: [snip] >> What about adding a 3-min timeout on such caches? That way the admin can >> be assured that any changes will propagate to currently active >> connections within 3minutes.
This is exactly what I want to be able to say, "Changes to ACLs will propagate to all clients within X time period or some other useful metric." Here's one way I might do it... In imap4.h, add fields to the clientinfo structure to hold three ACL's: user's acl for a mailbox, anyone acl for a mailbox, owner's acl for a mailbox. Perhaps place these into a structure of their own, too. In imapcommands.c, add the ci->acl structure to calls to acl_has_right. In acl_has_right, we look to see if the acl structure we were passed describes this mailbox, and is within 300 seconds of now. If not, we select new rows and set the time using time(2). This handles both the cache expiry and the new-mailbox-has-been-selected situations. Then acl_has_right checks the cached ACLs and return a yes or no answer if one of the ACLs grants the proper rights according to our rules: owner irrevocably has all rights, user specific rights can grant or revoke, and if not specifically set per user, anyone rights can grant or revoke. This would also remove the acl_flags trickery and array lookups and implicit ownership checking done in db_acl_has_right, which is icky stuff. [snip] > > This all sounds pretty complicated to me. Wouldn't it be simpler to > update the acl for a folder when a user issues a "select" statement? > I see it like this: > The command that's most used is probably FETCH. FETCH will only be > issued by a client after a SELECT (Correct me if I'm wrong). So, > whenever a client issues a SELECT we update the internal mailbox_t > structure with the ACL for that mailbox. I put a list of the functions which call acl_has_right from imapcommands.c into the bugtracker. It's basically all of them. At the moment I'm considering just pulling the entire row at the top of each function and using it however many times needed (1 - 4, depending upon the function). At least this gives a more stable query so that it can be cached up the line (MySQL has its query cache, PostgreSQL probably has something similar?). But better would be to keep with some state structure. Aaron