Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 815482

Summary:	After installation of cyrus-sasl-gssapi Python clients must restrict mech_list to use ANONYMOUS
Product:	Red Hat Enterprise MRG	Reporter:	Trevor McKay <tmckay>
Component:	python-qpid	Assignee:	mick <mgoulish>
Status:	CLOSED DUPLICATE	QA Contact:	Stanislav Graf <sgraf>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	Development	CC:	jross, matt, mgoulish, sgraf, tross
Target Milestone:	---	Keywords:	Reopened
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-12-10 20:56:36 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Trevor McKay 2012-04-23 17:10:00 UTC

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:

Comment 1 Ted Ross 2012-04-23 17:24:34 UTC

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.

Comment 2 Ted Ross 2012-04-23 17:26:19 UTC

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.

Comment 3 Trevor McKay 2012-04-23 17:41:23 UTC

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.

Comment 5 Stanislav Graf 2012-04-23 18:31:10 UTC

(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

Comment 6 Jeff Needle 2012-06-22 02:13:37 UTC

*** Bug 834390 has been marked as a duplicate of this bug. ***

Comment 7 Justin Ross 2012-12-10 20:56:36 UTC

Addressed in bug 846465.

*** This bug has been marked as a duplicate of bug 846465 ***