Learn more about these different git repos.
Other Git URLs
In the rare case when two or more authentication request from the same user happen to run at the same time we might end up with different credential cache file for each session if randomize credential cache files are configured. The only way to solve this is to keep track of the currently running authentication requests and delay an authentication request for a user if he has a request already running.
I'm not sure if it is worth the effort to add this check or if it would be enough to note the this in the man page and documentation.
If the same user is already logging in and using a password, we should probably just compare the 2 password and make one single request if they match. What would be the point of doing multiple identical requests at the same time ?
Well, it's possible a user might have a script around to open four ssh sessions to a system at the same time, for example.
I think you're right that we should treat auth requests similarly to how we do user information lookups in NSS (maintain a dhash table of events in progress) and key them uniquely by username and password.
Presumably if the passwords are the same, then we want to make sure they get back the same ccache, and with only one lookup to the server. If they're different, we want to make sure they remain parallel so that the one that's actually correct (if any) takes place and gets its appropriate reply.
Fields changed
milestone: NEEDS_TRIAGE => SSSD 1.4.0
owner: sbose => jhrozek
owner: jhrozek => jzeleny
status: new => assigned
A discussion took place on IRC regarding this ticket. We found out, that bundling requests in responder isn't good approach - the whole concept is based on sending one request to backend for all simultaneous PAM requests with the same user and password. But that could break some automated test checking compliance with password policy (SSSD would essentially mask N unsuccessful login attempts as only one attempt).
Therefore a better solution is to serialize the requests. For each PAM request, the responder would send a request to all data providers. Until the response is given for this pending request, all other PAM requests will be in waiting state.
Although this idea is better that the first one, it is likely an over-engineered solution for current issue - different krb5 cache files for simultaneously created PAM requests. Therefore it was decided to fix this issue directly in krb5 provider by creating the name of file and counting references to it. If more PAM requests are received simultaneously, the first one arriving in krb5 provider will set the name and all others will re-use it. The name shall be discarded once all references to it disappear.
While this issue is being fixed, it is probably a good idea to discuss the serialization of PAM requests as future feature. I'll compose an email starting the discussion and send it to sssd-devel mailing list.
Fixed by 7d436b1
coverity: => resolution: => fixed status: assigned => closed
rhbz: => 0
Metadata Update from @sbose: - Issue assigned to jzeleny - Issue set to the milestone: SSSD 1.5.0
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/1575
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.