Learn more about these different git repos.
Other Git URLs
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.
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.
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
Linked to Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=741210
rhbz: 741210 => [https://bugzilla.redhat.com/show_bug.cgi?id=741210 741210]
resolution: => wontfix
status: new => closed
Metadata Update from @jhrozek:
- Issue set to the milestone: SSSD Patches welcome
to comment on this ticket.