#4094 sss_client: usage of srand()/rand() may be disruptive for the user of lib
Closed: Fixed a year ago by pbrezina. Opened a year ago by atikhonov.

There are srand() (recently added) and rand() (was there for ages) functions used in common.c : sss_cli_open_socket().

This may be disruptive for an application that depends on deterministic PRNG behaviour.

While such a dependency may be a sign of a bad design of an application, still I think sss_client libs may be merciful and avoid touching state of libc PRNG for no good reason.

There is an (unproven) assumption that this may be the cause of https://bugzilla.redhat.com/show_bug.cgi?id=1755643

rand() function is used in sss_cli_open_socket() for the randomization of the delay before next attempt to connect after previous one failed with EAGAIN. This was done to avoid "thundering herd issues".

I see the following ways to handle this:

(1) I do not see potential for the "thundering herd issue" at all. And even if there is, randomization as it is done (strictly 1 or 2 secs) would not help much.
So I would vote to get rid of this randomization at all.

(2) To replace srand()/rand() with getrandom() as proposed in https://bugzilla.redhat.com/show_bug.cgi?id=1755643#c31
But getrandom() is Linux-specific and was only added to glibc in version 2.25, so it might have portability issues.

(3) To use rand_r() with any initial seed (because this is totally non security relevant functionality)

@sbose, @pbrezina, @mzidek, @thalman, what do you think?


Metadata Update from @atikhonov:
- Issue assigned to atikhonov

a year ago

ad 1) I'm not sure if it is needed. As far as i can tell the code was taken from winbind so the use case might have been different there. I do not see a need for this randomization for SSSD either but that does not mean one does not exist. However, since simo did not oppose I would incline to this option.

ad 2) Changes will go only to master anyway so I would not be worried about portability. Quick check show that it would be fine on at least RHEL, Fedora, Debian and Ubuntu. I agree with simo statement: What I am saying is that AIX compatibility shouldn't be a relevant factor in using better interfaces on other platforms.

ad 3) Might work as well.

However, it might be worth finding the true issue - i.e. why srand() here breaks things.

ad 1) I'm not sure if it is needed. As far as i can tell the code was taken from winbind so the use case might have been different there. I do not see a need for this randomization for SSSD either but that does not mean one does not exist. However, since simo did not oppose I would incline to this option.

PR: https://github.com/SSSD/sssd/pull/900

However, it might be worth finding the true issue - i.e. why srand() here breaks things.

This is tracked in corresponding bz.

Metadata Update from @atikhonov:
- Issue tagged with: PR

a year ago

This is the wrong way round. The bugzilla https://bugzilla.redhat.com/show_bug.cgi?id=1755643 is about the regression in Fedora 30+. It should be used to bring back working setup for FreeIPA as quickly as possible.

Then this (or some other) issue can be used for however long it it going to take to find the root cause and fix the behaviour properly.

This is the wrong way round.

All I want to say: this ticket != bz755643

  • master
    • e47f143 - SSS_CLIENT: got rid of using PRNG

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/5058

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