#1421 selinux rules are never deleted from sysdb
Closed: Fixed None Opened 9 years ago by jhrozek.

When processing SELinux rules, we always download all enabled rules, then filter out those that apply to the user who is logging in and then only save those that matched into the sysdb.

However, we never delete any rules, which means that a rule that is deleted or disabled on the server is left in the cache forever.

Given that we download all the rules anyway, I think we might as well delete and then save all rules into the sysdb on every login and then filter them out when processing the rules.

Are there any performance implication of getting all rules every time?

This needs to be fixed in beta5 due today.

owner: somebody => jhrozek
patch: 0 => 1
status: new => assigned

We are already downloading all the rules from the server every time, the difference is that in the current master, we only save rules that apply to the current user to sysdb. However, in order to do so, we were contacting the server again to resolve seeAlso attributes. I think that saving all the rules every time would actually be faster, because we wouldn't perform the second resolution.

I think we could implement something similar to ipa_hbac_refresh so that SELinux rules are not downloaded every time if multiple logins happen very closely after one another.

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.9.0 beta 5

resolution: => fixed
status: assigned => closed

Fields changed

rhbz: => 0

Metadata Update from @jhrozek:
- Issue assigned to jhrozek
- Issue set to the milestone: SSSD 1.9.0 beta 5

5 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/2463

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.