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", it will be stored as "fred". The problem is that when "fred" creates a connection and then sends messages with userId => "fred", 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:
See QPID-943 upstream.
*** Bug 531844 has been marked as a duplicate of this bug. ***
Bugfix committed upstream: svn r819819 http://svn.apache.org/viewvc/qpid/trunk/qpid/cpp/src/qpid/broker/SemanticState.cpp?revision=819819&view=markup
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?
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")
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.
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.
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
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