[PROTON-1209] [proton-c] Overhaul SASL

• Type: Improvement
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Affects Version/s: proton-0.10
• Component/s: proton-c
• Labels: sasl
• Assignee: Andrew Stitcher
• Reporter: Michael Goulish
• Created: 19/May/16 19:26
• Updated: 22/Feb/18 15:50

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).

Issue Links

• depends upon: PROTON-1500 Allow plugin SASL implementations
• is a clone of: PROTON-992 Proton's use of Cyrus SASL is not thread-safe - short term fix
• is duplicated by: PROTON-989 Multi-threaded creation of outgoing connections can crash inside the Cyrus SASL library
• is duplicated by: PROTON-970 SASL options for setting path and name should not be transport-specific
• is related to: PROTON-969 Cyrus SASL module calls sasl_server_init once for every incoming connection
• relates to: PROTON-862 Proton using Cyrus SASL library is problematic because the library has global state