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

RE: PATCH: cache_groupacl {on|off}



> -----Original Message-----
> From: owner-openldap-devel@OpenLDAP.org
> [mailto:owner-openldap-devel@OpenLDAP.org]On Behalf Of Diego Rivera

> This patch is applicable to OpenLDAP 2.1.22, but it MAY be
> applicable to
> the current snapshots.
>
> It allows turning on/off the caching of Group ACL
> evaluations, to force
> group ACL evaluation every time.  In my particular setup, the side
> effect from the caching that the ACL would be "frozen" at its initial
> evaluation and never refreshed posed a problem.
>
> The performance hit was acceptable, in exchange for the added security
> consistency.  YMMV, and use only when 100% necessary according to your
> particular setups.
>
> So I came up with this config option to allow startup-time
> selection of
> behavior.  The default is "on" , to match the same behavior as if the
> patch were not present.

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.)

"consistency" is somewhat open to interpretation. If I bind and execute a
search that produces a large result set, and I have permission to read all of
the results when the request was issued, I personally would expect to receive
the entire result set, even if my permissions changed while I was bound. In
general I believe this is a pretty rare occurrence, as most user requests are
small and most connections are short-lived. Most long-lived connections tend
to be application servers, and their privileges tend to change rarely if
ever.

I guess my philosophy reflects the Unix security model. I.e., Unix only
checks permissions on an object when you first open it. Once you have an open
handle, you can continue to use it regardless of subsequent permission
changes on the object. After you close the handle, you of course must pass
the checks again to perform another open. Also, Unix assigns group
memberships at login time. Changes to your group memberships will only affect
a subsequent login, not any currently active sessions.

There's been some discussion on the LDAPbis mailing list that's somewhat
relevant, re: whether the LDAP server should drop your connection if the
entity you bound as is deleted while you are connected. My personal feeling,
of course, is No.

At any rate, I suspect there are other folks who may share your view who will
speak up.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support