[jira] [Commented] (DISPATCH-224) Tools fail with no useful error in some SASL configurations

["Ted Ross (JIRA)" <ji...@apache.org>]

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

Ted Ross commented on DISPATCH-224:
-----------------------------------

The issue here is that even though authenticatePeer is set to "no", the SASL negotiation still occurs, picking the most secure available mechanism.  This should probably be raised against Proton.
The problem can be worked around by restricting the available SASL mechanisms by adding a saslMechanisms attribute to the default listener.


> Tools fail with no useful error in some SASL configurations
> -----------------------------------------------------------
>
>                 Key: DISPATCH-224
>                 URL: https://issues.apache.org/jira/browse/DISPATCH-224
>             Project: Qpid Dispatch
>          Issue Type: Bug
>          Components: Documentation
>    Affects Versions: 0.5
>            Reporter: Alan Conway
>            Assignee: Ted Ross
>            Priority: Critical
>             Fix For: 0.7.0
>
>
> (Downgraded to a doc issue, but still a serious one. See [#comment-15323200])
> A simple test of a default install of dispatch in /usr/local does not work:
> {code}
> $ make install
> $ qdrouterd&
> $ qdstat -g
> ConnectionException: Connection amqp://0.0.0.0:amqp/$management disconnected
> {code}
> The exception gives no hint why we were disconnected, and the router log file has no entries at all regarding the disconnection. The actual cause is a SASL rejection due to invalid configuration. There are several issues that need fixing:
> - The router log should show an error if SASL cant find/parse its config file.
> - The router log should show an error if a connection is rejected for security reasons.
> - The client exception should indicate that the disconnect was caused by a security problem.
> - The router should look for SASL configuration under its install prefix since that is where it is installed.
> - The default router configuration needs to be updated to either be functional or clearly NON functional.
> Question is is what should the default configuration allow? IMO it should at least allow you to use the tools shipped with qdrouterd to verify that it is running and working.
> The alternative is don't ship a default config at all. In that case the router should fail to start at all with a clear message "you must configure me first, see $prefix/share/doc/qdrouter/config-examples." We can provide a sample "qdrouterd-insecure.conf" to get developers started quickly without forcing them to learn SASL first. We can add other example configs for different scenarios as we go.



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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org