On ti, 18 syys 2018, Jan Parcel wrote:
I have not had time to look at all the docs to see what changed, but
we have had a problem here with a multi-threaded program calling
sasl_client_init multiple times in parallel and getting crashes and
hangs.
I've found various comments inside code and on the web about which
routines are vs. are not thread-safe, including that the sasl_set_*
routines are not, but I have not seen anything
that says "make sure you don't have parallel calls to sasl_client_init"
Can there be some kind of note somewhere about thread safety?
Sometime, if I have time, I will be trying to make sasl_client_init
thread-safe if possible, probably using static pthread locks (in a
library, static locks are the ONLY way to guarantee
no parallel mutex lock creation, which is a big no-no) but I got stuck
on a non-sasl customer issue which might take me a long time.
It used to be not possible to run SASL server and SASL client in the
same application at the same time with GSSAPI plugin as it was using the
same static lock for both. I changed that to use per-context locks. As
long as you are not sharing the same SASL context among multiple threads
with GSSAPI, there shouldn't be a problem. GSSAPI itself is blocking but
Cyrus-SASL will not block threads working on different SASL contexts.
This cannot be extended to other plugins. digestmd5 uses a single
reauth cache entry lock shared among all contexts. krb4 deals with
non-threaded kerberos4 library and thus has a single static lock. It is
mostly dead as krb4 is quite rare to see in real life. Other plugins
don't use locking at all.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
