[
https://issues.apache.org/jira/browse/PROTON-992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14802937#comment-14802937
]
Andrew Stitcher commented on PROTON-992:
----------------------------------------
Upon a few days reflection I've realised that you cannot fix this problem with
a global init for proton:
This is because there are a couple of parameters of the Cyrus library that
*must* be set before calling either sasl_server_init() or sasl_client_init().
These are the configuration file directory and the server name. Currently if
you want to customise these you must set them before the first usage of SASL
and this works as SASL is initialised lazily. However in the proposed API there
is literally no place to set them:
Since the usage pattern has to be documented that you must initialise the
library before using it the Cyrus Sasl ibrary will be initialised before you
are allowed to use the APIs that set the path or name.
So I think the only workable solution is to have an atomic count of use of the
library and initialise on the going from 0->1 then finalise on going from 1->0.
Obviously also keeping track of how many uses the library has as well so that
we can finalise in the correct place. An important point here is to make the
count atomic so that we can be sure to avoid any re-entrance into the
initialisation or finalisation code (this is doable using gcc/clang builtins -
we don't really support Cyrus on Win32 so Visual Studio isn't too important,
but it has atomic primitives too)
I would note that really we should alos be using atomic counts like this in the
OpenSSL code too,.
> 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)
