#1047 Optimize HBAC rule lookups with modifyTimestamp
Closed: wontfix 4 years ago by pbrezina. Opened 12 years ago by sgallagh.

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.


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.

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.7.0

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.

Fields changed

owner: sgallagh => jzeleny

Fields changed

milestone: SSSD 1.7.0 => SSSD Deferred

Fields changed

rhbz: => 0

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

Fields changed

priority: critical => major

Metadata Update from @sgallagh:
- Issue assigned to jzeleny
- Issue set to the milestone: SSSD Patches welcome

7 years ago

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.

Metadata Update from @pbrezina:
- Issue close_status updated to: wontfix
- Issue status updated to: Closed (was: Open)

4 years ago

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/2089

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.

Metadata