#1049 Check id ranges when returning entries from cache

Created 5 years ago by jhrozek
Modified 3 days ago

SSSD only performs ID range checks when the entry is saved into the cache. The NSS responder returns entry when it's cached and not expires without ID checks.

This can be confusing when a user changes ID ranges but still sees entries returned from cache with IDs out of range.

This is even bigger problem for the local provider because the local backend is essentially a cache that never expires.

Fields changed

rhbz: => 741210

I think it is reasonable to expect the user to run the command to clean the caches when fundamental configuration is changed.

The local case is harder, but then if you really want to change the range you should also really check and remove/change users that fall off the range.

The reason why I am not so hot in enforcing the range in the responder is that we will not really be able to do that when we will have the read-only mmap cache shared with the clients. We would have to have code that regularly scans and remove out of range entries to maintain similar behaviour, which is costly and not sure really in scope.

Another way though is to store the range into the cache in the base entry and check if it matches the current configuration at startup. And if it doesn't either autoremoves all the caches or at least removes the offending entries.

This means the change of ranges must have effect only if you restart SSSD though.

HTH

The above comment sounds reasonable and would turn this ticket into a documentation issue.

Expire the cache if configuration changes.

milestone: NEEDS_TRIAGE => SSSD Deferred

Fields changed

blockedby: =>
blocking: =>
feature_milestone: =>
resolution: => wontfix
status: new => closed

3 days ago

Metadata Update from @jhrozek:
- Issue set to the milestone: SSSD Patches welcome

Login to comment on this ticket.

defect

SSSD

1.6.2

0

0

https://bugzilla.redhat.com/show_bug.cgi?id=741210

cancel