Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CLIENT: fix thread unsafe acces to get*ent structs. #6333

Closed

Conversation

alexey-tikhonov
Copy link
Member

All get*ent structs were protected with socket mutex. In case SSSD
is built with lock-free client support, sss_nss_lock() is a no-op,
thus resulting in thread unsafe access.

This patch changes those structs to have thread local storage.

This conradicts following note in the man page:

The function getgrent_r() is not really reentrant since it shares
the reading position in the stream with all other threads.

I'm not sure if 3rd party apps can legally assume this behaviour
based on a note in a man page. And in some cases, non-sharing reading
position between threads might make more sense.
But that way or another, this is better than thread unsafe access.

All get*ent structs were protected with socket mutex. In case SSSD
is built with lock-free client support, `sss_nss_lock()` is a no-op,
thus resulting in thread unsafe access.

This patch changes those structs to have thread local storage.

This conradicts following note in the man page:
```
The function getgrent_r() is not really reentrant since it shares
the reading position in the stream with all other threads.
```
I'm not sure if 3rd party apps can legally assume this behaviour
based on a note in a man page. And in some cases, non-sharing reading
position between threads might make more sense.
But that way or another, this is better than thread unsafe access.
@sumit-bose
Copy link
Contributor

Hi,

to make those structures thread-local seems like a proper way to me to protect them against parallel access. I think we can ignore the case where e.g. setpwent() and endpwent() are not called inside the same thread but by different ones. According the man pages those calls are not thread safe, so spreading them over different threads does not sound like something we have to care about but should be fixed on the caller side.

bye,
Sumit

@pbrezina
Copy link
Member

pbrezina commented Sep 2, 2022

I agree. Ack.

@pbrezina
Copy link
Member

Pushed PR: #6333

  • master
    • 69fd828 - CLIENT: fix thread unsafe acces to get*ent structs.
  • sssd-2-7
    • 181d6fb - CLIENT: fix thread unsafe acces to get*ent structs.

@pbrezina pbrezina added Pushed and removed Accepted Ready to push Ready to push labels Sep 16, 2022
@pbrezina pbrezina closed this Sep 16, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport-to-stable Targets also latest stable branch Pushed
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants