Andrew Stitcher created PROTON-862:

             Summary: Proton using Cyrus SASL library is problematic because 
the library has global state
                 Key: PROTON-862
             Project: Qpid Proton
          Issue Type: Bug
    Affects Versions: 0.10
            Reporter: Andrew Stitcher

The Cyrus SASL library is not 100% suitable for use in other libraries because 
it has global state and needs to be globally initialised before use as either a 
SASL client or SASL server. One requirement for this global initialisation 
seems to be to load the mechanism plugins.

This global state is problematic because we cannot dictate what the linked in 
application and other libraries may do with Cyrus SASL themselves.

In particular we currently use the sasl_server_init() call to set the basename 
for the config file that is used for the SASL settings. It is possible to work 
around this by passing in NULL instead of a name and so not changing whatever 
the application may have set. However we will then need to set the Cyrus SASL 
options "manually" by implementing the SASL_CB_GETOPT callback which returns 
the options set in the config file, so that we don't need Cyrus to do it for us.

Even so we would still have to be setting the global callbacks to NULL in our 
initialisation, as there is no way to make Cyrus ignore the global callback 
initialisation - this implies that for correct interop no library (and probably 
no application either) can ever set these global callbacks, as they will have 
no way to ensure that some random library loaded in doesn't reset them!

Another (perhaps better) alternative would be to port Proton to use another 
SASL library, which better respects being used in a library and has no global 
state. A good example of this would be libgsasl. However its API is 
significantly more complex to use, largely because it doesn't do the user 
authentication part itself and requires the application or dependant library to 
do it.

This message was sent by Atlassian JIRA

Reply via email to