Bug 652233 - qpid tools bad behaviour if PLAIN authentication is forced
Summary: qpid tools bad behaviour if PLAIN authentication is forced
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: qpid-qmf
Version: 1.3
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: 2.1
: ---
Assignee: Ken Giusti
QA Contact: Lubos Trilety
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-11-11 12:46 UTC by Lubos Trilety
Modified: 2011-08-12 16:02 UTC (History)
7 users (show)

Fixed In Version: python-qmf-0.9.1073306-1, qpid-tools-0.9.1078967-1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-06-23 15:42:47 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2011:0890 0 normal SHIPPED_LIVE Red Hat Enterprise MRG Messaging 2.0 Release 2011-06-23 15:42:41 UTC

Description Lubos Trilety 2010-11-11 12:46:18 UTC
Description of problem:
By default qpid tools does not authenticate to the broker when PLAIN authentication method is forced in qpid sasl config.
After such attempt some of them (like qpid-config, qpid-stat, qpid-cluster, qpid-queue-stats, qpid-route) print that no mechanism is available, which is not true. Moreover qpid-stat prints some not-handled exception.
Others (qpid-printevents, qpid-tool) looks like they are working correctly, but they aren't connected, so it's not true either.

Version-Release number of selected component (if applicable):
qpid-tools-0.7.946106-11

How reproducible:
100%

Steps to Reproduce:
1. set 'auth=yes' in /etc/qpidd.conf and 'mech_list: PLAIN' in /etc/sasl2/qpidd.conf, start qpidd service

2. run 'qpid-stat -c'
# qpid-stat -c
Failed: ConnectionFailed - (None, 'SASL error: Error in sasl_client_start (-4) SASL(-4): no mechanism available: No worthy mechs found')
Traceback (most recent call last):
  File "/usr/bin/qpid-stat", line 530, in ?
    bm.SetBroker(_host)
  File "/usr/bin/qpid-stat", line 157, in SetBroker
    self.broker = self.qmf.addBroker(brokerUrl, _connTimeout)
  File "/usr/lib/python2.4/site-packages/qmf/console.py", line 639, in addBroker
    ssl = url.scheme == URL.AMQPS, connTimeout=timeout)
  File "/usr/lib/python2.4/site-packages/qmf/console.py", line 2070, in __init__
    raise self.conn_exc
qpid.connection.ConnectionFailed: (None, 'SASL error: Error in sasl_client_start (-4) SASL(-4): no mechanism available: No worthy mechs found')

3. run 'qpid-tool' try to print schema
# qpid-tool
Management Tool for QPID
qpid: schema
QMF Classes:
  
Actual results:
step 2: the program print that no mechanism is available + traceback
step 3: the qpid-tool looks like it works correctly but all action returns empty result. If 'qpid-stat -c guest/guest@localhost' is run in another terminal, it can be checked that there is no qpid-tool connection to broker

Expected results:
for step 2 and 3 it should print correct error, that authentication failed

Additional info:

Comment 1 Lubos Trilety 2010-11-11 13:14:09 UTC
This bug is not dependant on architecture the same behaviour is observed on both x86_64 and i386 architectures.
The described scenario is relevant for RHEL5, for RHEL4 it was very similar only the error message was slightly different, on RHEL4 it is:
Failed: ConnectionFailed: (None, 'No acceptable SASL authentication mechanism available')
instead of:
Failed: ConnectionFailed - (None, 'SASL error: Error in sasl_client_start (-4)
SASL(-4): no mechanism available: No worthy mechs found')

The bug was detected on these sasl and qpid packages:
cyrus-sasl-plain-2.1.22-5.el5_4.3
cyrus-sasl-2.1.22-5.el5_4.3
saslwrapper-devel-0.1.934605-2.el5
cyrus-sasl-plain-2.1.22-5.el5_4.3
saslwrapper-0.1.934605-2.el5
ruby-saslwrapper-0.1.934605-2.el5
cyrus-sasl-lib-2.1.22-5.el5_4.3
cyrus-sasl-lib-2.1.22-5.el5_4.3
cyrus-sasl-devel-2.1.22-5.el5_4.3
python-saslwrapper-0.1.934605-2.el5
cyrus-sasl-devel-2.1.22-5.el5_4.3
qpid-cpp-server-store-0.7.946106-19.el5
qpid-cpp-server-devel-0.7.946106-19.el5
qpid-tests-0.7.946106-1.el5
qpid-cpp-server-0.7.946106-19.el5
python-qpid-0.7.946106-14.el5
qpid-cpp-client-ssl-0.7.946106-19.el5
qpid-cpp-server-xml-0.7.946106-19.el5
qpid-cpp-client-devel-docs-0.7.946106-19.el5
qpid-cpp-mrg-debuginfo-0.7.946106-19.el5
qpid-java-client-0.7.946106-12.el5
qpid-cpp-client-0.7.946106-19.el5
qpid-cpp-server-ssl-0.7.946106-19.el5
qpid-cpp-server-cluster-0.7.946106-19.el5
qpid-cpp-client-devel-0.7.946106-19.el5
qpid-tools-0.7.946106-11.el5
qpid-java-common-0.7.946106-12.el5
qpid-java-example-0.7.946106-12.el5

Comment 2 Jonathan Robie 2010-12-20 19:14:30 UTC
How are you supplying the user name and password? [1]

If I omit the user name and password, I get similar results to what you are getting. If I add the user name and password to the URL, I can use qpid-stat with SASL without difficulty:

qpid-stat -c guest/guest@localhost:5672

Connections
  client-addr      cproc      cpid   auth        connected  idle  msgIn  msgOut
  ===============================================================================
  127.0.0.1:54085  qpid-stat  30413  guest@QPID  0s         0s     203      0


[1] http://www.ietf.org/rfc/rfc4616.txt

Comment 3 Lubos Trilety 2010-12-21 08:28:48 UTC
That's the point to not supply user name and password.

There are two possible solutions:
First use default user name and password (guest/guest) if PLAIN mechanism is forced.
Second print correct error. Definitely not something like: "no mechanism available: No worthy mechs found". (In case of qpid-printevents and qpid-tool the tool doesn't print anything, but it should, because it's not connected to broker)

Comment 4 Jonathan Robie 2010-12-21 18:52:03 UTC
(In reply to comment #3)
> That's the point to not supply user name and password.
> 
> There are two possible solutions:
> First use default user name and password (guest/guest) if PLAIN mechanism is
> forced.

I don't think the tools should do this. If you enable a SASL mechanism that requires a user name and password, I expect the system to require a name and password.

> Second print correct error. Definitely not something like: "no mechanism
> available: No worthy mechs found".

We simply use cyrus sasl as a framework, this is not a message that is generated by the tools themselves. I think these tools should continue to treat authentication as a black box.

> (In case of qpid-printevents and qpid-tool
> the tool doesn't print anything, but it should, because it's not connected to
> broker)

It's not an error for qpid-printevents and qpid-tool to run without being connected to a broker. These tools are designed for environments in which brokers may come up and go down, so you can start them, then start a broker, take the broker down, etc.

However, when a broker is available and these tools fail to connect due to an authentication error, these tools should report that error.

Comment 5 Jonathan Robie 2010-12-22 22:23:43 UTC
In upstream revision 1052086, I added a few things that you may find helpful:

1. I added some log messages to the QMF console.

   If a connection can't be made because no broker is available, it is
   logged as a warning. If a connection can't be made because of a
   SASL authentication error, it is logged as an error.

2. I set the default logging level to ERROR for both qpid-tool and
   qpid-printevents.

   This means the user sees an error for SASL authentication, but not
   for a broker that is not running yet.

3. I added a --require-connection option to qpid-printevents. If a
   connection can not be established, the program exits.

4. I have added a --log-level option to qpid-printevents.

Examples: 

$ ./qpid-printevents --sasl-mechanism PLAIN nonexistent-broker

=> Not an error. Waits for the broker to be started.

$ ./qpid-printevents --sasl-mechanism PLAIN localhost
2010-12-22 17:07:18,365 ERROR Could not connect to broker localhost:5672 (None, 'No acceptable SASL authentication mechanism available')

=> Connection error condition in output - SASL authentication failed
   because user name and password are not supplied.

   But qpid-printevents keeps running, waiting for you to start the
   broker.

$ ./qpid-printevents --sasl-mechanism PLAIN --log-level critical

=> Connection error condition in output - SASL authentication failed
   because user name and password are not supplied.

   No output in this case, because the log level has been set to
   critical.

$ ./qpid-printevents --sasl-mechanism PLAIN --require-connection localhost
2010-12-22 17:11:03,791 ERROR Could not connect to broker localhost:5672 (None, 'No acceptable SASL authentication mechanism available')
Failed: ConnectionFailed - (None, 'No acceptable SASL authentication mechanism available')

=> Connection error condition.

   qpid-printevents terminates because --require-connection was specified.

Comment 6 Jonathan Robie 2011-01-10 13:50:54 UTC
Revision 1052086 was reverted. A simpler fix has been made in revision 1057195.

If the broker is not up, you get errors like this:

$ ./qpid-printevents localhost:41234
Fri Jan  7 22:30:22 2011 NOTIC qpid-printevents:brokerConnectionFailed broker=localhost:41234 [Errno 111] Connection refused
Fri Jan  7 22:30:23 2011 NOTIC qpid-printevents:brokerConnectionFailed broker=localhost:41234 [Errno 111] Connection refused

Comment 7 Lubos Trilety 2011-05-26 08:33:32 UTC
Tested on:
qpid-tools-0.10-4.el6
qpid-tools-0.10-5.el5

'auth=yes' in /etc/qpidd.conf was set

qpid-printevents works fine
# qpid-printevents localhost:41234
Thu May 26 08:30:50 2011 NOTIC qpid-printevents:brokerConnectionFailed broker=localhost:41234 (111, 'Connection refused')
Thu May 26 08:30:51 2011 NOTIC qpid-printevents:brokerConnectionFailed broker=localhost:41234 (111, 'Connection refused')

but qpidd-tool still doesn't print any error
# qpid-tool localhost:41234
Management Tool for QPID
qpid: schema
QMF Classes:
qpid: list
Summary of Objects by Type:

>>> ASSIGNED

Comment 11 Ken Giusti 2011-06-02 17:00:00 UTC
Missed 2.0 release train - pushing out to next release.

Comment 12 errata-xmlrpc 2011-06-23 15:42:47 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHEA-2011-0890.html


Note You need to log in before you can comment on or make changes to this bug.