Qpid
  1. Qpid
  2. QPID-2949

broker prompts console interactively for password when --auth=no

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 0.8
    • Fix Version/s: 0.9
    • Component/s: C++ Broker
    • Labels:
      None

      Description

      As a result of checkin svn r1024541, which promoted some client-side Sasl code to the common library for use in broker, the broker now prompts for a password when when it is run with --auth=no !

      The attached patch removes this behavior by propagating knowledge of "--auth=no" down to SaslFactory. If authorization has been turned off, the Saslfactory will create a null sasl object, just like it does if the code is compiled with no Sasl support.

      TODO – also must fix the pathway where auth==yes.

      NOTE: this is apparently an irritant rather than a disaster, since it did not affect make check after the original checkin ( r102451 ).

      1. dont_prompt_me_2.diff
        5 kB
        michael j. goulish

        Activity

        Hide
        michael j. goulish added a comment -

        fixed in revision 1040689

        Show
        michael j. goulish added a comment - fixed in revision 1040689
        Hide
        Steve Huston added a comment -

        This patch broke the Windows build:

        ..\..\qpid\cpp\src\qpid\client\windows\SaslFactory.cpp(105) : error C2511: 'std::auto_ptr<_Ty> qpid::SaslFactory::create(const std::string &,const std::string &,const std::string &,const std::string &,int,int)' : overloaded member function not found in 'qpid::SaslFactory'

        please see http://www.riverace.com/CDash-1.4.2/viewBuildError.php?buildid=1032 for more info, but the above error is the one that matters.

        Show
        Steve Huston added a comment - This patch broke the Windows build: ..\..\qpid\cpp\src\qpid\client\windows\SaslFactory.cpp(105) : error C2511: 'std::auto_ptr<_Ty> qpid::SaslFactory::create(const std::string &,const std::string &,const std::string &,const std::string &,int,int)' : overloaded member function not found in 'qpid::SaslFactory' please see http://www.riverace.com/CDash-1.4.2/viewBuildError.php?buildid=1032 for more info, but the above error is the one that matters.
        Hide
        michael j. goulish added a comment -

        obsoletes previous patch

        this patch provides a way to tell SaslFactory that console interaction is NOT ok. i.e. if the code is running as part of a broker, or a demonized client of some kind. Just tell it to never do interaction, and any attempt to interact will be treated as an error.

        This script demonstrates that all goes well if you supply enough info :

        rm -rf /tmp/data_1 /tmp/data_2
        mkdir /tmp/data_1 /tmp/data_2

        1. in window 1:
          ../qpidd -p 5672 --data-dir /tmp/data_1 --auth=yes --mgmt-enable=yes --log-enable info+ ./qpidd_1.log --log-source yes --sasl-config=/home/mick/trunk/qpid/cpp/src/tests/sasl_config
        1. in window 2:
          ../qpidd -p 10000 --data-dir /tmp/data_2 --auth=yes --mgmt-enable=yes --log-enable info+ ./qpidd_1.log --log-source yes --sasl-config=/home/mick/trunk/qpid/cpp/src/tests/sasl_config
        1. in window 3 ( from qpid dir )
          ./tools/src/py/qpid-route dynamic add zig/zig@localhost zig/zig@localhost:10000 qmf.default.direct
        2. and view the created route
          ./tools/src/py/qpid-route route list localhost:5672

        If you say auth=no, that works fine also.

        HOWEVER PLEASE NOTE –

        if you say auth=yes, but then do not supply enough into to avoid the need for interaction, the attempted interaction will result in the connection being closed. Then the originating broker will re-try the connection, and you will get a two-broker infinite loop until you fix it.

        Show
        michael j. goulish added a comment - obsoletes previous patch this patch provides a way to tell SaslFactory that console interaction is NOT ok. i.e. if the code is running as part of a broker, or a demonized client of some kind. Just tell it to never do interaction, and any attempt to interact will be treated as an error. This script demonstrates that all goes well if you supply enough info : rm -rf /tmp/data_1 /tmp/data_2 mkdir /tmp/data_1 /tmp/data_2 in window 1: ../qpidd -p 5672 --data-dir /tmp/data_1 --auth=yes --mgmt-enable=yes --log-enable info+ ./qpidd_1.log --log-source yes --sasl-config=/home/mick/trunk/qpid/cpp/src/tests/sasl_config in window 2: ../qpidd -p 10000 --data-dir /tmp/data_2 --auth=yes --mgmt-enable=yes --log-enable info+ ./qpidd_1.log --log-source yes --sasl-config=/home/mick/trunk/qpid/cpp/src/tests/sasl_config in window 3 ( from qpid dir ) ./tools/src/py/qpid-route dynamic add zig/zig@localhost zig/zig@localhost:10000 qmf.default.direct and view the created route ./tools/src/py/qpid-route route list localhost:5672 If you say auth=no, that works fine also. HOWEVER PLEASE NOTE – if you say auth=yes, but then do not supply enough into to avoid the need for interaction, the attempted interaction will result in the connection being closed. Then the originating broker will re-try the connection, and you will get a two-broker infinite loop until you fix it.
        Hide
        michael j. goulish added a comment -

        obsoletes previous patch

        this patch provides a way to tell SaslFactory that console interaction is NOT ok. i.e. if the code is running as part of a broker, or a demonized client of some kind. Just tell it to never do interaction, and any attempt to interact will be treated as an error.

        This script demonstrates that all goes well if you supply enough info :

        rm -rf /tmp/data_1 /tmp/data_2
        mkdir /tmp/data_1 /tmp/data_2

        1. in window 1:
          ../qpidd -p 5672 --data-dir /tmp/data_1 --auth=yes --mgmt-enable=yes --log-enable info+ ./qpidd_1.log --log-source yes --sasl-config=/home/mick/trunk/qpid/cpp/src/tests/sasl_config
        1. in window 2:
          ../qpidd -p 10000 --data-dir /tmp/data_2 --auth=yes --mgmt-enable=yes --log-enable info+ ./qpidd_1.log --log-source yes --sasl-config=/home/mick/trunk/qpid/cpp/src/tests/sasl_config
        1. in window 3 ( from qpid dir )
          ./tools/src/py/qpid-route dynamic add zig/zig@localhost zig/zig@localhost:10000 qmf.default.direct
        2. and view the created route
          ./tools/src/py/qpid-route route list localhost:5672

        If you say auth=no, that works fine also.

        HOWEVER PLEASE NOTE –

        if you say auth=yes, but then do not supply enough into to avoid the need for interaction, the attempted interaction will result in the connection being closed. Then the originating broker will re-try the connection, and you will get a two-broker infinite loop until you fix it.

        Show
        michael j. goulish added a comment - obsoletes previous patch this patch provides a way to tell SaslFactory that console interaction is NOT ok. i.e. if the code is running as part of a broker, or a demonized client of some kind. Just tell it to never do interaction, and any attempt to interact will be treated as an error. This script demonstrates that all goes well if you supply enough info : rm -rf /tmp/data_1 /tmp/data_2 mkdir /tmp/data_1 /tmp/data_2 in window 1: ../qpidd -p 5672 --data-dir /tmp/data_1 --auth=yes --mgmt-enable=yes --log-enable info+ ./qpidd_1.log --log-source yes --sasl-config=/home/mick/trunk/qpid/cpp/src/tests/sasl_config in window 2: ../qpidd -p 10000 --data-dir /tmp/data_2 --auth=yes --mgmt-enable=yes --log-enable info+ ./qpidd_1.log --log-source yes --sasl-config=/home/mick/trunk/qpid/cpp/src/tests/sasl_config in window 3 ( from qpid dir ) ./tools/src/py/qpid-route dynamic add zig/zig@localhost zig/zig@localhost:10000 qmf.default.direct and view the created route ./tools/src/py/qpid-route route list localhost:5672 If you say auth=no, that works fine also. HOWEVER PLEASE NOTE – if you say auth=yes, but then do not supply enough into to avoid the need for interaction, the attempted interaction will result in the connection being closed. Then the originating broker will re-try the connection, and you will get a two-broker infinite loop until you fix it.
        Hide
        Ted Ross added a comment -

        >>TODO – also must fix the pathway where auth==yes.

        This is important since the problem isn't the state of the --auth configuration but the fact that a server process is prompting for interactive input.

        >>NOTE: this is apparently an irritant rather than a disaster, since it did not affect make check
        >>after the original checkin ( r102451 ).

        I disagree with this statement. All this means is that make-check has insufficient coverage. If a server process is hanging while waiting for interactive input, I'd say that's closer to disaster than irritant.

        Show
        Ted Ross added a comment - >>TODO – also must fix the pathway where auth==yes. This is important since the problem isn't the state of the --auth configuration but the fact that a server process is prompting for interactive input. >>NOTE: this is apparently an irritant rather than a disaster, since it did not affect make check >>after the original checkin ( r102451 ). I disagree with this statement. All this means is that make-check has insufficient coverage. If a server process is hanging while waiting for interactive input, I'd say that's closer to disaster than irritant.
        Hide
        michael j. goulish added a comment -

        This supersedes the previous patch.
        Keeping the "isAuthenticatng()" broker predicate,
        but not passing information down in call-tree.
        much cleaner this way.

        Show
        michael j. goulish added a comment - This supersedes the previous patch. Keeping the "isAuthenticatng()" broker predicate, but not passing information down in call-tree. much cleaner this way.
        Hide
        michael j. goulish added a comment -

        I was probably wrong to assign blocker status to this. I believe it
        really is just an irritant, since even in the auth=no case I can still
        successfully use qpid-route to create a route between two brokers, while
        ignoring the spurious prompt.

        I'm going to change this to 0.9 to get it out of the way of the release,
        and then just fix this on trunk.

        Show
        michael j. goulish added a comment - I was probably wrong to assign blocker status to this. I believe it really is just an irritant, since even in the auth=no case I can still successfully use qpid-route to create a route between two brokers, while ignoring the spurious prompt. I'm going to change this to 0.9 to get it out of the way of the release, and then just fix this on trunk.
        Hide
        michael goulish added a comment -

        Robbie –

        I was probably wrong to assign blocker status to this. I believe it
        really is just an irritant, since even in the auth=no case I can still
        successfully use qpid-route to create a route between two brokers, while
        ignoring the spurious prompt.

        I'm going to change this to 0.9 to get it out of the way of the release,
        and then just fix this on trunk.

        ---------------------------------- Mick .

        Show
        michael goulish added a comment - Robbie – I was probably wrong to assign blocker status to this. I believe it really is just an irritant, since even in the auth=no case I can still successfully use qpid-route to create a route between two brokers, while ignoring the spurious prompt. I'm going to change this to 0.9 to get it out of the way of the release, and then just fix this on trunk. ---------------------------------- Mick .
        Hide
        Robbie Gemmell added a comment -

        Hi Michael,

        I see that you have tagged this issue Fix For 0.8 originally, but later updated your comment to suggest the issue is only an irritant. Do you still think this needs to be fixed for 0.8, and if so do you intend to do so?

        I think it could be concerning enough for users to see the broker requesting passwords that it would be good to fix it for 0.8 if the change is reasonable, especially if as your comments now suggest its also an issue when auth=yes....but the JIRAs current Minor status is almost as far from Blocker as it gets. Let me know what you think as there wont be much point producing another RC until this goes in, if it going to.

        Robbie

        Show
        Robbie Gemmell added a comment - Hi Michael, I see that you have tagged this issue Fix For 0.8 originally, but later updated your comment to suggest the issue is only an irritant. Do you still think this needs to be fixed for 0.8, and if so do you intend to do so? I think it could be concerning enough for users to see the broker requesting passwords that it would be good to fix it for 0.8 if the change is reasonable, especially if as your comments now suggest its also an issue when auth=yes....but the JIRAs current Minor status is almost as far from Blocker as it gets. Let me know what you think as there wont be much point producing another RC until this goes in, if it going to. Robbie
        Hide
        michael j. goulish added a comment -

        This patch prevents the broker from prompting for a password when auth == no by sending that info down to the SaslFactory, through Connection and ConnectionHandler. The SaslFactory will create a null sasl object.

        Show
        michael j. goulish added a comment - This patch prevents the broker from prompting for a password when auth == no by sending that info down to the SaslFactory, through Connection and ConnectionHandler. The SaslFactory will create a null sasl object.

          People

          • Assignee:
            michael j. goulish
            Reporter:
            michael j. goulish
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development