[ 
https://issues.apache.org/jira/browse/PROTON-992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14741025#comment-14741025
 ] 

Alan Conway commented on PROTON-992:
------------------------------------

According to the SASL docs, the existing use of the SASL lib is just flat 
wrong. If existing apps that make more than one connection work, it is a fluke 
and any minor change of version in Cyrus might cause them to break in a 
difficult to diagnose way. The header files and doc from the latest 
cyrus-sasl-2.1.26 are very clear:

 *  sasl_client_init  Load and initialize client plug-ins (call once)
 *  sasl_server_init  Load and initialize server plug-ins (call once)

We could, to preserve backwards compat, set a flag in the per-process init and 
check that flag and re-run the (incorrect) init per connection if the 
per-process init is not called. That would allow people to write correct code 
in future but keep existing code (e.g. single connection apps) working.

It would be nice to avoid the explicit per-process call entirely but IMO there 
is no way to do an "exactly once" call in C without some form of locking, which 
is why most C libraries do have explicit "setup/shutdown" calls that have to be 
made from main(). I would like to keep proton "thread free", and not introduce 
an external locking hack like SASL has done.




> Proton's use of Cyrus SASL is not thread-safe.
> ----------------------------------------------
>
>                 Key: PROTON-992
>                 URL: https://issues.apache.org/jira/browse/PROTON-992
>             Project: Qpid Proton
>          Issue Type: Bug
>          Components: proton-c
>    Affects Versions: 0.10
>            Reporter: michael goulish
>            Assignee: michael goulish
>            Priority: Critical
>
> 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).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to