Bug 519505 - Broker strips domain from userID, causes mismatch on GSSAPI id checking
Summary: Broker strips domain from userID, causes mismatch on GSSAPI id checking
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: qpid-cpp
Version: 1.1.6
Hardware: All
OS: Linux
high
medium
Target Milestone: 1.3
: ---
Assignee: Ken Giusti
QA Contact: Martin Kudlej
URL:
Whiteboard:
: 531844 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-08-26 21:13 UTC by Ted Ross
Modified: 2010-10-14 16:07 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Due to incorrect stripping of a domain from the "userId" string, connecting to a broker using Kerberos authentication may have caused the messages sent to the broker to be rejected as unauthorized. With this update, the broker was adjusted to store the entire "userID", so that the value can be correctly compared with the string that is sent by a client.
Clone Of:
Environment:
Last Closed: 2010-10-14 16:07:52 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2010:0773 normal SHIPPED_LIVE Moderate: Red Hat Enterprise MRG Messaging and Grid Version 1.3 2010-10-14 15:56:44 UTC

Description Ted Ross 2009-08-26 21:13:25 UTC
Description of problem:

There's an issue with the way userId checking is done in the C++ broker.  The broker, when it stores the userId for a connection (line 68 in qpid/broker/SemanticState.cpp), strips the domain portion of the ID.  So if the userId is "fred@domain.com", it will be stored as "fred".

The problem is that when "fred@domain.com" creates a connection and then sends messages with userId => "fred@domain.com", the messages are rejected because the strings don't match.

Having the client strip the domain before producing a message seems incorrect since important information is lost.  Also, a consumer which is using the vouched-for userId for its own purposes will need the domain text.

I propose that userIds not be tampered with by the broker.  Will this cause a problem with the JMS clients? 

Version-Release number of selected component (if applicable):

1.1.6

How reproducible:

100%

Steps to Reproduce:
1. Run a Qpid broker with Kerberos5 enabled and configured
2. Modify ruby/lib/qpid/qmf.rb (from svn) by uncommenting line 1557 (this sets the userID header with the user who is current via kinit).
3. Establish a connection using the Ruby QMF console (the same file that was just edited).
  
Actual results:

The connection will be established correctly, and all messages sent via that connection will be rejected with an UnauthorizedAccessException.

Expected results:

The messages should be accepted normally by the broker.

Additional info:

Comment 1 Ted Ross 2009-08-26 21:14:19 UTC
See QPID-943 upstream.

Comment 3 Gordon Sim 2009-10-30 10:42:46 UTC
*** Bug 531844 has been marked as a duplicate of this bug. ***

Comment 6 Martin Kudlej 2010-10-05 14:14:21 UTC
I've got version from 20091016 from candidate(ruby-qpid-0.4.749380-2.el5) and there is nothing to uncomment on line 1557. Is this proper version to reproduce this issue? Which line should I uncomment/comment, please write here context of those lines? Is there any other reproducer for this issue, please?

Comment 7 Ted Ross 2010-10-05 14:24:47 UTC
The line is now at 1530.  Here is the context:

    def message(body, routing_key="broker", ttl=nil)
      dp = @amqp_session.delivery_properties
      dp.routing_key = routing_key
      dp.ttl = ttl if ttl
      mp = @amqp_session.message_properties
      mp.content_type = "x-application/qmf"
      mp.reply_to = amqp_session.reply_to("amq.direct", @reply_name)
      #mp.user_id = @user_id if @user_id                            <===== !!!
      return Qpid::Message.new(dp, mp, body)
    end

    def emit(msg, dest="qpid.management")

Comment 8 Ken Giusti 2010-10-05 14:54:28 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
* Cause:  connecting to the broker using kerberos authentication.
* Consequence:  Messages sent to the broker are rejected as Unauthorized.
* Fix:  the broker stores the entire userId string for the connection rather than truncating off the "@domain" portion.
* Result: the broker's stored user id will correctly match full user id strings sent by clients.

Comment 9 Jaromir Hradilek 2010-10-05 17:53:44 UTC
    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1,4 +1 @@
-* Cause:  connecting to the broker using kerberos authentication.
+Due to incorrect stripping of a domain from the "userId" string, connecting to a broker using Kerberos authentication may have caused the messages sent to the broker to be rejected as unauthorized. With this update, the broker was adjusted to store the entire "userID", so that the value can be correctly compared with the string that is sent by a client.-* Consequence:  Messages sent to the broker are rejected as Unauthorized.
-* Fix:  the broker stores the entire userId string for the connection rather than truncating off the "@domain" portion.
-* Result: the broker's stored user id will correctly match full user id strings sent by clients.

Comment 10 Martin Kudlej 2010-10-07 08:02:33 UTC
Reproduced in 
ruby-qpid-0.4.749380-2.el5
qpidc-0.5.752581-28.el5
qpidd-0.5.752581-28.el5
and it doesn't work.

Tested in 
qpid-java-client-0.7.946106-10.el5
ruby-qpid-0.7.946106-2.el5
qpid-cpp-server-0.7.946106-17.el5
qpid-java-common-0.7.946106-10.el5
qpid-cpp-client-devel-0.7.946106-17.el5
qpid-cpp-client-0.7.946106-17.el5
and it works. --> VERIFIED

Comment 12 errata-xmlrpc 2010-10-14 16:07:52 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/RHSA-2010-0773.html


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