Qpid
  1. Qpid
  2. QPID-3614

ACLs and federation links do not work

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Not A Problem
    • Affects Version/s: 0.12
    • Fix Version/s: None
    • Component/s: C++ Broker
    • Labels:
    • Environment:

      Built from source on ubuntu 10.04 x64

      Description

      PROBLEM STATEMENT:
      I cannot get broker federation to work with ACLs enabled. I keep getting "ACL denied creating a federation link" even though my user has all permissions, on both brokers.

      STEPS TO REPRODUCE:

      • Create an acl file like the following:
        acl allow federation@QPID all all
        acl deny all all
      • Create the federation user in the sasl db
      • Using the following config:
        auth-realm=QPID
        log-enable=info+
        acl-file=/usr/local/etc/qpid/qpidd.acl
        sasl-config=/usr/local/etc/sasl2
        auth=yes
      • Start two brokers using the same config but different ports and data dirs (makes it easy to test the exact same authentication parameters for both brokers)
      • In my case I am create a queue push route, so create a queue and do:
        qpid-route queue add -s federation/password@localhost:5000 federation/password@localhost:5001 amq.direct myqueue

      Note that the use of a push route does not matter, I tested push and pull and both fail, just want to point out that I am using a push route to ensure that gets tested as part of the fix for this.

      RESULTS:
      The connection fails to get created with an error: "ACL denied creating a federation link"
      In the debug log on the destination broker I see:
      2011-11-11 15:50:20 debug ACL: Lookup for id: action:create objectType:link name: with params { }
      2011-11-11 15:50:20 debug No successful match, defaulting to the decision mode deny

      It appear that the user ID is not getting sent across

      EXPECTED RESULTS:
      The federation link should work with proper ACLs in place

        Activity

        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open Closed Closed
        1049d 16h 11m 1 Gordon Sim 26/Sep/14 16:06
        Gordon Sim made changes -
        Field Original Value New Value
        Resolution Not a Problem [ 8 ]
        Status Open [ 1 ] Closed [ 6 ]
        Hide
        Justin Ross added a comment -

        Gordon Sim, can this be closed?

        Show
        Justin Ross added a comment - Gordon Sim , can this be closed?
        Hide
        Gordon Sim added a comment -

        Sorry, critical typo in my comment! I meant to say 'it appears that transfers are not subject to authorisation unless there are specific, explicit rules about it'. (I'll fix that comment as well).

        I.e. there is no checking of permission to publish a message to an exchange unless there is an explicit rule relating to publication in the ACL (as far as I can see from reading the code). If you add a 'deny all publish all' as the second last line then you would turn authorisation for publication on, and without authenticating as federation publications would fail even if permission to create the link were granted to all.

        Show
        Gordon Sim added a comment - Sorry, critical typo in my comment! I meant to say 'it appears that transfers are not subject to authorisation unless there are specific, explicit rules about it'. (I'll fix that comment as well). I.e. there is no checking of permission to publish a message to an exchange unless there is an explicit rule relating to publication in the ACL (as far as I can see from reading the code). If you add a 'deny all publish all' as the second last line then you would turn authorisation for publication on, and without authenticating as federation publications would fail even if permission to create the link were granted to all.
        Hide
        Brandon Pedersen added a comment -

        I am confused how messages would be published to the exchange then if not authenticated as the user specified during the route creation. In my current working setup the only permission I provide to anonymous is the ability to create a link:
        acl allow all create link

        Everything else has to be authenticated, i.e. publish messages to an exchange. So if the messages being published to the destination exchange (using the federation link) are using anonymous, how is that possible if there is not an acl to allow that?...or maybe I am misunderstanding your comment...

        Show
        Brandon Pedersen added a comment - I am confused how messages would be published to the exchange then if not authenticated as the user specified during the route creation. In my current working setup the only permission I provide to anonymous is the ability to create a link: acl allow all create link Everything else has to be authenticated, i.e. publish messages to an exchange. So if the messages being published to the destination exchange (using the federation link) are using anonymous, how is that possible if there is not an acl to allow that?...or maybe I am misunderstanding your comment...
        Hide
        Gordon Sim added a comment - - edited

        I don't believe it does use the specified user to publish messages, the connection underlying the link was authenticated as anonymous (in my tests anyway). Looking through the source code, it appears that transfers are not subject to authorisation unless there are specific, explicit rules about it (comments indicate this is due to concerns around performance otherwise).

        Sadly I don't think this is documented, though the mechanism is listed as an option in the usage statement for qpid-route.

        Show
        Gordon Sim added a comment - - edited I don't believe it does use the specified user to publish messages, the connection underlying the link was authenticated as anonymous (in my tests anyway). Looking through the source code, it appears that transfers are not subject to authorisation unless there are specific, explicit rules about it (comments indicate this is due to concerns around performance otherwise). Sadly I don't think this is documented, though the mechanism is listed as an option in the usage statement for qpid-route.
        Hide
        Brandon Pedersen added a comment -

        Great, that did work for me. Is there a reason it uses anonymous by default for creating the link? It seems odd that it uses anonymous to create the link, but the specified user to actually publish messages once the link is up. Also, do you know if this is documented? I couldn't find it in the documentation.

        thanks

        Show
        Brandon Pedersen added a comment - Great, that did work for me. Is there a reason it uses anonymous by default for creating the link? It seems odd that it uses anonymous to create the link, but the specified user to actually publish messages once the link is up. Also, do you know if this is documented? I couldn't find it in the documentation. thanks
        Hide
        Gordon Sim added a comment -

        Try adding an explicit SASL mechanism for the route:

        qpid-route queue add -s federation/password@localhost:5000 federation/password@localhost:5001 amq.direct myqueue PLAIN

        For me this works even with your original ACL. Without specifying PLAIN, the connection from localhost:5001 to localhost:5000 authenticates as anonymous (assuming that's enabled) and it is the anonymous user that is then checked for permission to create the federation link.

        Show
        Gordon Sim added a comment - Try adding an explicit SASL mechanism for the route: qpid-route queue add -s federation/password@localhost:5000 federation/password@localhost:5001 amq.direct myqueue PLAIN For me this works even with your original ACL. Without specifying PLAIN, the connection from localhost:5001 to localhost:5000 authenticates as anonymous (assuming that's enabled) and it is the anonymous user that is then checked for permission to create the federation link.
        Hide
        Brandon Pedersen added a comment -

        Apparently this is just the actual link creation that doesn't include the right authentication information. I added a line to the ACL file like this:
        acl allow all create link

        And added tighter restrictions on the federation user and it looks like it is working correctly, the messages are able to be published to the right exchange using the other ACLs I created, and I also notice in the log just AFTER the link is created: "info 66.135.39.60:5672-67.199.170.100:61532 SASL: Authentication succeeded for: federation@QPID"

        Show
        Brandon Pedersen added a comment - Apparently this is just the actual link creation that doesn't include the right authentication information. I added a line to the ACL file like this: acl allow all create link And added tighter restrictions on the federation user and it looks like it is working correctly, the messages are able to be published to the right exchange using the other ACLs I created, and I also notice in the log just AFTER the link is created: "info 66.135.39.60:5672-67.199.170.100:61532 SASL: Authentication succeeded for: federation@QPID"
        Brandon Pedersen created issue -

          People

          • Assignee:
            Unassigned
            Reporter:
            Brandon Pedersen
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development