Bug 617477 - qpid python client (low level api) fails to authenticate using GSSAPI method ('Unspecified GSS failure...')
qpid python client (low level api) fails to authenticate using GSSAPI method ...
Status: CLOSED NOTABUG
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: python-qpid (Show other bugs)
beta
All Linux
high Severity high
: 1.3
: ---
Assigned To: messaging-bugs
Frantisek Reznicek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-07-23 04:18 EDT by Frantisek Reznicek
Modified: 2015-11-15 20:12 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-08-05 07:35:33 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
simple test script (2.13 KB, text/plain)
2010-07-30 06:09 EDT, Gordon Sim
no flags Details

  None (edit)
Description Frantisek Reznicek 2010-07-23 04:18:26 EDT
Description of problem:

The qpid python client fails GSSAPI authentication in the case user and credentials are valid.

There are observed continuous failure of python qpid client on RHEL 5.5 i386 / x86_64 following ways:


RHEL 5.5 i386: ('...Unspecified GSS failure.  Minor code
  may provide more information (Server not found in Kerberos database)')

  qc_client.py --conn-auth-mechanism GSSAPI -p 49759 --user 343u2psaofS6PpWa3hZMn --broker pogolinux-1.rhts.eng.rdu.redhat.com
  Cannot connect to the broker pogolinux-1.rhts.eng.rdu.redhat.com:49759
  Traceback (most recent call last):
    File "/mnt/tests/distribution/MRG/Messaging/qpid_common/clients/python/qc_lib.py", line 236, in connect
      self.connection.start();
    File "/usr/lib/python2.4/site-packages/qpid/connection.py", line 152, in start
      raise ConnectionFailed(*self.close_code)
  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 (Server not found in Kerberos database)')
  Traceback (most recent call last):
    File "/mnt/tests/distribution/MRG/Messaging/qpid_common/clients/python/qc_client.py", line 30, in ?
      sys.exit(main());
    File "/mnt/tests/distribution/MRG/Messaging/qpid_common/clients/python/qc_client.py", line 18, in main
      qc.connect();
    File "/mnt/tests/distribution/MRG/Messaging/qpid_common/clients/python/qc_lib.py", line 243, in connect
      raise QcException(e);
  qc_lib.QcException: <qpid.connection.ConnectionFailed instance at 0xb7dfb2ec>
  Exception qc_lib.QcException: <qc_lib.QcException instance at 0xb7dfb2ec> in <bound method qc_client.__del__ of <qc_lib.qc_client object at 0xb7e9b
  c8c>> ignored
  ecode:1


RHEL 5.5 x86_64 ('...Unspecified GSS failure.  Minor code
  may provide more information (Unknown code krb5 7)'):

  qc_client.py --conn-auth-mechanism GSSAPI -p 41042 --user EH0ncsAo3bT7EkT6XgBc --broker tyan-gt24-04.rhts.eng.bos.redhat.com
  Cannot connect to the broker tyan-gt24-04.rhts.eng.bos.redhat.com:41042
  Traceback (most recent call last):
    File "/mnt/tests/distribution/MRG/Messaging/qpid_common/clients/python/qc_lib.py", line 236, in connect
      self.connection.start();
    File "/usr/lib/python2.4/site-packages/qpid/connection.py", line 152, in start
      raise ConnectionFailed(*self.close_code)
  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 7)')
  Traceback (most recent call last):
    File "/mnt/tests/distribution/MRG/Messaging/qpid_common/clients/python/qc_client.py", line 30, in ?
      sys.exit(main());
    File "/mnt/tests/distribution/MRG/Messaging/qpid_common/clients/python/qc_client.py", line 18, in main
      qc.connect();
    File "/mnt/tests/distribution/MRG/Messaging/qpid_common/clients/python/qc_lib.py", line 243, in connect
      raise QcException(e);
  qc_lib.QcException: <qpid.connection.ConnectionFailed instance at 0x2aedc7291d88>
  Exception qc_lib.QcException: <qc_lib.QcException instance at 0x9409dd0> in <bound method qc_client.__del__ of <qc_lib.qc_client object at 0x2aedc7
  28b910>> ignored
  ecode:1

I believe the printed error messages are misleading, but I might be wrong.

The client used for GSSAPI authentication is simple qc_client.py
which can be found here:
http://cvs.devel.redhat.com/cgi-bin/cvsweb.cgi/tests/distribution/MRG/Messaging/qpid_common/clients/python/

Connection's host parameter is set to FQDN or ip (equal to broker host name) of the machine where kerberos daemons are running:

  def connect(self):
    try:
      self.socket = qpid.util.connect(self.options.broker_host,
                                      self.options.broker_port);

      conn_opts_dict = { };
      # optional authentication assignments
      if(self.options.conn_auth_mechanism == 'GSSAPI'):
        conn_opts_dict['host'] = self.options.broker_host;
      if(self.options.auth_user != None):
        conn_opts_dict['username'] = self.options.auth_user;
      if(self.options.auth_pass != None):
        conn_opts_dict['password'] = self.options.auth_pass;
      if(self.options.conn_auth_mechanism != None):
        conn_opts_dict['mechanism'] = self.options.conn_auth_mechanism;
      if(self.options.conn_auth_service != None):
        conn_opts_dict['service'] = self.options.conn_auth_service;
      if(self.options.conn_auth_min_ssf != None):
        conn_opts_dict['min_ssf'] = self.options.conn_auth_min_ssf;
      if(self.options.conn_auth_max_ssf != None):
        conn_opts_dict['max_ssf'] = self.options.conn_auth_max_ssf;

      self.connection = Connection( sock = self.socket,
                              heartbeat = self.options.conn_heartbeat,
                              locale = self.options.conn_locale,
                              **conn_opts_dict );

      # start connection and session
      # ---------------------------------------------------------------------
      self.connection.start();


The test was passing, but suddenly with one of the last releases it started to fail.


Version-Release number of selected component (if applicable):
python-qmf-0.7.946106-5.el5
python-qpid-0.7.946106-4.el5
python-saslwrapper-0.1.934605-2.el5
qmf-0.7.946106-6.el5
qmf-devel-0.7.946106-6.el5
qpid-cpp-client*-0.7.946106-6.el5
qpid-cpp-server*-0.7.946106-6.el5
qpid-java-*-0.7.946106-5.el5
qpid-tests-0.7.946106-1.el5
qpid-tools-0.7.946106-6.el5

but seen also on the very last packages from devel repo.

How reproducible:
100%

Steps to Reproduce:
0. All necessary kerberos, cyrus-sasl and saslwrapper packages are installed.
   Kerberos service is set-up for current machine for admin user
   admin@EXAMPLE.COM and unprivileged user EH0nc@EXAMPLE.COM

1. User get's his kerberos ticket using kinit
2. Broker (qpidd)  is started up with --auth yes
3. qpid python client is executed to get connection to the broker using GSSAPI authentication:
   qc_client.py --conn-auth-mechanism GSSAPI -p 41042 --user EH0ncs \
                --broker tyan-gt24-04.rhts.eng.bos.redhat.com
Actual results:
Qpid python client (low level API) fails GSSAPI authentication under normal conditions when it should pass.

Expected results:
Qpid python client (low level API) should pass GSSAPI authentication under normal conditions.

Additional info:

See more detailed info on the following links:
https://beaker.engineering.redhat.com/logs/2010/09/7009/12443/146859///TESTOUT.log
https://beaker.engineering.redhat.com/logs/2010/09/7009/12443/146859///log.tar.bz2

or
https://beaker.engineering.redhat.com/logs/2010/72/8372/14934/183553///TESTOUT.log
https://beaker.engineering.redhat.com/logs/2010/72/8372/14934/183553///log.tar.bz2
Comment 1 Gordon Sim 2010-07-30 06:09:53 EDT
Created attachment 435519 [details]
simple test script

Works for me using attached script (modified from one of the old examples) and latest packages in -devel (python-qpid-0.7.946106-9.el5, python-saslwrapper-0.1.934605-2.el5).

The 'Server not found in Kerberos database' error suggests that the principal for the qpidd service on the given machine has not been created. Might that have expired? Has the qc_client.py code changed at all?
Comment 2 Frantisek Reznicek 2010-08-02 04:36:05 EDT
I'm going to retest, there were some changes to qc_client.py, but I believe those were harmless.

The changes made to qc_client.py are passing dynamically arguments to Connection, passing there dictionary with dynamic Connection's argument. I need doublecheck, the only change I can see is that I do not pass password as it is not needed in krb case.


An update soon.
Comment 3 Frantisek Reznicek 2010-08-05 07:06:14 EDT
I performed retest of the case and found following issue:
The comment 1 client works as expected, because Connection's 'service' parameter is explicitly defined as 'qpidd'.

The qc_client.py now performs also testing of default values, so the Connection code changed from below mode 0 to mode 3:
if (mode==0):
  connection = Connection (sock=socket, 
                           username=options.auth_user, 
                           mechanism=options.conn_auth_mechanism, 
                           host=options.broker_host,
                           service=options.conn_auth_service);
elif(mode==1):
  connection = Connection (sock=socket, 
                           username=options.auth_user, 
                           mechanism=options.conn_auth_mechanism, 
                           host=options.broker_host);
elif(mode==2):
  connection = Connection (sock=socket, 
                           username=options.auth_user, 
                           mechanism=options.conn_auth_mechanism, 
                           host=options.broker_host,
                           service='qpidd');
elif(mode==3):
  conn_opts_dict = { };
  if(options.conn_auth_mechanism == 'GSSAPI'):
    conn_opts_dict['host'] = options.broker_host;
  if(options.auth_user != None):
    conn_opts_dict['username'] = options.auth_user;
  if(options.conn_auth_mechanism != None):
    conn_opts_dict['mechanism'] = options.conn_auth_mechanism;
  if(options.conn_auth_service != None):
    conn_opts_dict['service'] = options.conn_auth_service;
  
  connection = Connection (sock=socket, **conn_opts_dict);


Conclusion:
The qpid python GSSAPI authentication works as expected if Connection's service parameter is explicitly specified.


The remaining question:
To my understanding Connection's service parameter should default to 'qpidd' anyway, so explicit assignment is not needed.
Am I right?
Comment 4 Frantisek Reznicek 2010-08-05 07:35:33 EDT
The behavior was discussed and agreed that Connection's service parameter should default to 'qpidd'.
To avoid confusion closing this bug as CLOSED/NOTABUG and created new one with appropriate description of the failure and setting i.e bug 621527.

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