[jira] [Commented] (PROTON-862) Proton using Cyrus SASL library is problematic because the library has global state
[ https://issues.apache.org/jira/browse/PROTON-862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14588574#comment-14588574 ] ASF subversion and git services commented on PROTON-862: Commit 0f90a7e4c9cc5a1decd7f6896c16d9b8b0653316 in qpid-proton's branch refs/heads/master from [~astitcher] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=0f90a7e ] PROTON-909: Rearrange the test code to create the Cyrus SASL configuration - Make the Cyrus SASL configuration global for all the testing - This fixes test failures against earlier versions of the Cyrus library - The bug this fixes relates to PROTON-862 Proton using Cyrus SASL library is problematic because the library has global state --- Key: PROTON-862 URL: https://issues.apache.org/jira/browse/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. So at this point this route would involve significant extra work, although might be long term more maintainable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-862) Proton using Cyrus SASL library is problematic because the library has global state
[ https://issues.apache.org/jira/browse/PROTON-862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14511864#comment-14511864 ] Rafael H. Schloming commented on PROTON-862: It strikes me that we could probably structure things such that the initialization problem is punted to the application. For example, we could by default use the same fallback code that is currently used when cyrus is not available. We can then provide an API for the application to tell us to start using cyrus instead of the fallback. This way the application can do the cyrus initialization however it chooses and then if/when the application has initialized cyrus, it can tell us to start using it. Proton using Cyrus SASL library is problematic because the library has global state --- Key: PROTON-862 URL: https://issues.apache.org/jira/browse/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. So at this point this route would involve significant extra work, although might be long term more maintainable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
