Optimize HBAC rule lookups with modifyTimestamp

[sssd-bot]

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/1047

• Created at 2011-10-19 21:09:58 by sgallagh
• Closed at 2020-03-24 14:21:53 as wontfix
• Assigned to jzeleny

---

Currently, we refresh the HBAC rules every time we perform an access-control check while online. This is painfully slow on machines with very large deployments (such as those with many hosts).

One way we can reduce this pain is by limiting our lookups by checking the entryUSN in a subtree search of the host, rule and service subtrees. If any entries have an entryUSN newer than lastUSN (or the current lastUSN value is smaller than the saved value) we should force a full update of the rules.

Otherwise, we should just evaluate from the cache for extremely significant gains.

Comments

---

Comment from jraquino at 2011-10-19 22:47:04

This approach seems sane, however, isn't it completely dependent on the timeout set for the cache in question? I.E. if the cache times out, and you attempt to login, regardless of if the FreeIPA HBAC data has changed, sssd is still going to attempt to refresh the entire HBAC ruleset...

Currently, if you ssh to a system with sssd configured with say a 10 minute hbac cache, the first login is slow, and for the remaining 10minutes, it will use the cache and have a very fast login.

The entryUSN method seems much more useful if the sssd daemon was polling independent of user login/interaction, with lookups computed for the lowest common denominator during authentications/authorizations rather than the full query.

---

Comment from dpal at 2011-10-20 14:52:47

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.7.0

---

Comment from sgallagh at 2011-10-20 15:02:10

The HBAC refresh timeout right now isn't actually a cache expiration. It's a grace period during which we won't attempt to perform an update (so we can handle a rash of 'acct' events in a short period). This means that with a 1 minute refresh timeout, all entries would get values from the cache for one full minute, irrespective of changes on the server.

This ticket is to add a second enhancement behind the refresh timeout. Meaning that if the refresh timeout has passed, we will first attempt to determine whether the update is worth doing (i.e. any of the relevant attributes have changed in LDAP). We can do this with a couple fast LDAP lookups. If nothing has changed, then we don't need to save the list into the cache again (which is where the big performance hit occurs).

So this two-level approach should handle most usage patterns. There's still a chance for additional optimization in the future (by doing delta updates rather than full updates) but that's a lot of work for dubious additional gain, so I'm proposing not to do that right now.

---

Comment from dpal at 2011-11-03 14:20:29

Fields changed

owner: sgallagh => jzeleny

---

Comment from dpal at 2011-11-03 14:42:40

Fields changed

milestone: SSSD 1.7.0 => SSSD Deferred

---

Comment from dpal at 2012-01-19 03:22:51

Fields changed

rhbz: => 0

---

Comment from jhrozek at 2016-10-14 14:17:34

Fields changed

blockedby: =>
blocking: =>
changelog: =>
design: =>
design_review: => 0
feature_milestone: =>
fedora_test_page: =>
mark: => 0
review: => 0
selected: =>
sensitive: => 0
summary: Optimize HBAC rule lookups with entryUSN => Optimize HBAC rule lookups with modifyTimestamp

---

Comment from jhrozek at 2016-10-14 14:17:55

Fields changed

priority: critical => major

---

Comment from sgallagh at 2017-02-24 14:46:03

Metadata Update from @sgallagh:

• Issue assigned to jzeleny
• Issue set to the milestone: SSSD Patches welcome

---

Comment from pbrezina at 2020-03-24 14:21:53

Thank you for taking time to submit this request for SSSD. Unfortunately this issue was not given priority and the team lacks the capacity to work on it at this time.

Given that we are unable to fulfill this request I am closing the issue as wontfix.

If the issue still persist on recent SSSD you can request re-consideration of this decision by reopening this issue. Please provide additional technical details about its importance to you.

Thank you for understanding.

---

Comment from pbrezina at 2020-03-24 14:21:54

Metadata Update from @pbrezina:

• Issue close_status updated to: wontfix
• Issue status updated to: Closed (was: Open)