Description of problem: If cyrus-sasl-gssapi is installed on a system with a default /etc/sasl2/qpidd.conf file, Python clients must be given a restricted mechanism list in order to make an ANONYMOUS connection. Version-Release number of selected component (if applicable): Reproduced on RHEL5 and RHEL6 with different flavors of qpid-0.14 packages How reproducible: 100% Steps to Reproduce: 1. Install a broker and qpid-tools. Leave /etc/sasl2/qpidd.conf with default setttings, note that the comment here indicates that PLAIN and ANONYMOUS are on by default. 2. Verify that cyrus-sasl-gssapi is not installed (rpm -q) 3. Run qpid-stat -c, verify that qpid-stat can connect to the broker. 4. yum install cyrus-sasl-gssapi 5. Run qpid-stat -c (should get error below) 6. Run qpid-stat -c --sasl-mechanism='ANONYMOUS' (success) Actual results: Failed: ConnectionFailed - (None, 'SASL error: Error in sasl_client_start (-1) SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Unknown code krb5 195)') Client is apparently trying to use GSSAPI unless the mech list is restricted. Expected results: I would expect connections to the broker without credentials specified to continue to use ANONYMOUS, particularly since the comment in /etc/sasl2/qpidd.con indicates only PLAIN and ANONYMOUS supported by default. Additional info:
I don't think this is a bug... SASL negotiates the most secure, mutually-agreed-upon mechanism between the client and server. If the client does not specify a list of mechanisms, the negotiation will choose the most secure available mechanism (in this case GSSAPI). There is no way for the client to use the "without credentials" condition because no credentials are supplied for a GSSAPI login. They are registered out-of-band by kinit. The possible solutions include: 1) Modifying the client to retry with ANONYMOUS if (a) it is available, and (b) the chosen mechanism failed; 2) Modify the API such that the user can see the list of available mechanisms before choosing one. In the absence of one of these new features, I claim that the current behavior is correct and expected.
Another note: The reproducer in the original post has the client and broker running on the same system. If gssapi is installed on the broker system but not on a remote client system, ANONYMOUS should work without restricting the list.
Ted, >> There is no way for the client to use the "without credentials" condition >> because no credentials are supplied for a GSSAPI login. They are registered >> out-of-band by kinit. I thought this might be the case except, for one thing. The default /etc/sasl2/qpidd.conf file says this: # This configuation allows for either SASL PLAIN or ANONYMOUS # authentication. The PLAIN authentication is done on a # username+password, which is stored in the sasldb_path # file. Usernames and passwords can be added to the file using the # command: I claim there is still a bug, because according to this comment, the server does not have GSSAPI enabled by default and so the client shouldn't try to use it. If the broker does have it enabled, then the comment needs to change because it's misleading. If it is not supposed to be enabled by default, then something else is wrong. Additionally, if it did not used to be enabled by default, but now is in 0.14, then we need a release note.
(In reply to comment #3) > Additionally, if it did not used to be enabled by > default, but now is in 0.14, then we need a release note. # rpm -q qpid-cpp-server qpid-cpp-server-0.10-9.el5.i386 # qpid-stat -c (working) # yum install -y cyrus-sasl-gssapi # service qpidd restart Stopping Qpid AMQP daemon: [ OK ] Starting Qpid AMQP daemon: [ OK ] # qpid-stat -c Failed: ConnectionFailed - (None, 'SASL error: Error in sasl_client_start (-1) SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (No credentials cache found)') ecode=1 /etc/sasl2/qpidd.conf file says this: # This configuation allows for either SASL PLAIN or ANONYMOUS # authentication. The PLAIN authentication is done on a # username+password, which is stored in the sasldb_path # file. Usernames and passwords can be added to the file using the # command: ---> Not a regression
*** Bug 834390 has been marked as a duplicate of this bug. ***
Addressed in bug 846465. *** This bug has been marked as a duplicate of bug 846465 ***