Description of problem: Authenticated method calls fail when PLAIN authentication is used from a Python console in the absence of python-saslwrapper. It appears from agent logs that the user is passed to AuthorizeMethod as "". Version-Release number of selected component (if applicable): rpm -qa | egrep -i "qpid|qmf|saslwrapper" el5: qpid-cpp-server-0.14-3.el5.i386 condor-qmf-7.6.5-0.12.el5.i386 python-saslwrapper-0.10-4.el5.i386 qpid-cpp-client-0.14-3.el5.i386 qpid-qmf-0.14-2.el5.i386 python-qpid-qmf-0.14-2.el5.i386 qpid-tools-0.14-1.el5.noarch python-qpid-0.14-1.el5.noarch saslwrapper-0.10-4.el5.i386 el6: qpid-cpp-client-0.14-1.el6.x86_64 qpid-cpp-client-devel-0.14-1.el6.x86_64 python-qpid-qmf-0.14-3.el6.x86_64 qpid-java-example-0.14-1.el6.noarch qpid-cpp-server-xml-0.14-1.el6.x86_64 qpid-qmf-0.14-3.el6.x86_64 qpid-java-common-0.14-1.el6.noarch qpid-cpp-server-devel-0.14-1.el6.x86_64 qpid-cpp-server-store-0.14-1.el6.x86_64 qpid-tools-0.14-1.el6.noarch qpid-cpp-client-devel-docs-0.12-6.el6.noarch ruby-qpid-qmf-0.14-3.el6.x86_64 qpid-java-client-0.14-1.el6.noarch saslwrapper-0.10-2.el6.x86_64 qpid-cpp-server-0.14-1.el6.x86_64 python-qpid-0.14-1.el6.noarch condor-qmf-7.6.5-0.12.el6.x86_64 ruby-saslwrapper-0.10-2.el6.x86_64 How reproducible: 100% (sgraf may have a smaller repro case that does not use cumin) Steps to Reproduce: 1. Install cumin, condor, and the broker and configure the broker fo plain authentication 2. Make sure of these cumin config settings: broker: cumin/cumin@localhost sasl-mech-list: plain 3. Set the SCHEDD_DEBUG = D_FULLDEBUG condor option in /etc/condor/config.d 4. $ yum install python-saslwrapper 5. $ cumin-admin add-user user 6. Run cumin and log is as user. Verify that submitting jobs from cumin works. 7. $ yum remove python-saslwrapper 8. $ service cumin restart 9. Try to submit from cumin. Result will be "Forbidden". 10. Search in /var/log/condor/SchedLog for "AuthorizeMethod". First submission should say "AuthorizeMethod: checking 'cumin'", second will say "AuthorizeMethod: checking ''" Actual results: Can't invoke methods that require authentication without python-saslwrapper installed when using plain Expected results: Shouldn't need python-saslwrapper for plain Additional info:
Created attachment 559116 [details] reproducer
Retested on RHEL 5.8 / 6.2 i[36]86 / x86_64 on packages: el5 python-qpid-0.14-6.el5 python-qpid-qmf-0.14-7.el5 qpid-cpp-*-0.14-16.el5 qpid-java-*-0.14-3.el5 qpid-qmf-*0.14-7.el5 qpid-tests-0.14-1.el5 qpid-tools-0.14-2.el5 rh-qpid-cpp-tests-0.14-16.el5 ruby-qpid-qmf-0.14-7.el5 ruby-saslwrapper-0.10-4.el5 saslwrapper-0.10-4.el5 saslwrapper-devel-0.10-4.el5 sesame-1.0-3.el5 el6 python-qpid-0.14-7.el6_2.noarch python-qpid-qmf-0.14-7.el6_2.i686 qpid-cpp-*-0.14-14.el6_2.i686 qpid-java-*-0.14-3.el6.noarch qpid-qmf-*0.14-7.el6_2.i686 qpid-tests-0.14-1.el6_2.noarch qpid-tools-0.14-2.el6_2.noarch rh-qpid-cpp-tests-0.14-14.el6_2.i686 ruby-qpid-qmf-0.14-7.el6_2.i686 ruby-saslwrapper-0.10-2.el6.i686 saslwrapper-0.10-2.el6.i686 saslwrapper-devel-0.10-2.el6.i686 sesame-1.0-5.el6.i686 At this point python client do not need python-saslwrapper package to be installed for PLAIN authentication. Reproducer: for i in localhost $(hostname) <specific-ip>; do spout_mod "ADDR_;{create:sender}" -c 1 -b guest/guest@${i}:5672 qpid-config --sasl-mechanism PLAIN -a guest/guest@${i}:5672 qpid-stat --sasl-mechanism PLAIN -c -b guest/guest@${i}:5672 qpid-printevents --sasl-mechanism PLAIN guest/guest@${i}:5672 qpid-tool guest/guest@${i}:5672 done Keeping in ASSIGNED, will be retested for target version.
(In reply to comment #9) > At this point python client do not need python-saslwrapper package to be > installed for PLAIN authentication. > > Reproducer: > for i in localhost $(hostname) <specific-ip>; do > spout_mod "ADDR_;{create:sender}" -c 1 -b guest/guest@${i}:5672 > qpid-config --sasl-mechanism PLAIN -a guest/guest@${i}:5672 > qpid-stat --sasl-mechanism PLAIN -c -b guest/guest@${i}:5672 > qpid-printevents --sasl-mechanism PLAIN guest/guest@${i}:5672 > qpid-tool guest/guest@${i}:5672 > done > > Keeping in ASSIGNED, will be retested for target version. Although above works, the issue is not fixed. This BZ needs to be tested with: Comment 0 Comment 9 Attachment 559116 [details]
Frantisek, it looks to me that this should be set MODI and targeted for some future version, maybe 2.4? Specifically, "Keeping in ASSIGNED, will be retested for target version." doesn't make sense to me.
I'm going to retest and update current status.