Description
Documentation for the Cyrus SASL library says that the library is believed to be thread-safe only if the code that uses it meets several requirements.
The requirements are:
- you supply mutex functions (see sasl_set_mutex())
- you make no libsasl calls until sasl_client/server_init() completes
- no libsasl calls are made after sasl_done() is begun
- when using GSSAPI, you use a thread-safe GSS / Kerberos 5 library.
It says explicitly that that sasl_set* calls are not thread safe, since they set global state.
The proton library makes calls to sasl_set* functions in :
pni_init_client()
pni_init_server(), and
pni_process_init()
Since those are internal functions, there is no way for code that uses Proton to lock around those calls.
I think proton needs a new API call to let applications call sasl_set_mutex(). Or something.
We probably also need other protections to meet the other requirements specified in the Cyrus documentation (and quoted above).
Attachments
Issue Links
- depends upon
-
PROTON-1500 Allow plugin SASL implementations
- Closed
- is a clone of
-
PROTON-992 Proton's use of Cyrus SASL is not thread-safe - short term fix
- Closed
- is duplicated by
-
PROTON-989 Multi-threaded creation of outgoing connections can crash inside the Cyrus SASL library
- Closed
-
PROTON-970 SASL options for setting path and name should not be transport-specific
- Closed
- is related to
-
PROTON-969 Cyrus SASL module calls sasl_server_init once for every incoming connection
- Closed
- relates to
-
PROTON-862 Proton using Cyrus SASL library is problematic because the library has global state
- Closed