Uploaded image for project: 'JBoss A-MQ'
  1. JBoss A-MQ
  2. ENTMQ-2309

Race Condition when Updating Users and Authorization Entries

    XMLWordPrintable

Details

    • Bug
    • Resolution: Not a Bug
    • Major
    • None
    • JBoss A-MQ 6.2.1
    • broker, jaas
    • None
    • Hide
      • Take an OOTB karaf-based broker distribution (I used AMQ 6.2.1-169), extract and configure it
      • Configure the runtimeConfigurationPlugin (not 100% it is needed, but is present in my reproducer environment):
        <runtimeConfigurationPlugin checkPeriod="60000" />
        
      • Start the container
      • While the container is running, add the following lines to the activemq.xml authorization map:
                            <authorizationEntry topic="test.input.>" read="testadm" write="testadm" admin="admin"/>
                            <authorizationEntry topic="test.>" read="test1" write="test1" admin="admin"/>
        
      • Next add a corresponding user to users.properties:
        testadm=testadm,testadm,admin
        
      • At the karaf console, try producing messages to a matching destination:
         activemq:producer --user testadm --password testadm --destination topic://test.input.MY-SUPER-TOPIC --message hello
        

      When starting with a clean broker, the above seems to fail 1 out of 3 or 4 times in my environment. Restarting the broker allows the command to complete successfully.

      Show
      Take an OOTB karaf-based broker distribution (I used AMQ 6.2.1-169), extract and configure it Configure the runtimeConfigurationPlugin (not 100% it is needed, but is present in my reproducer environment): <runtimeConfigurationPlugin checkPeriod= "60000" /> Start the container While the container is running, add the following lines to the activemq.xml authorization map: <authorizationEntry topic= "test.input.>" read= "testadm" write= "testadm" admin= "admin" /> <authorizationEntry topic= "test.>" read= "test1" write= "test1" admin= "admin" /> Next add a corresponding user to users.properties: testadm=testadm,testadm,admin At the karaf console, try producing messages to a matching destination: activemq:producer --user testadm --password testadm --destination topic: //test.input.MY-SUPER-TOPIC --message hello When starting with a clean broker, the above seems to fail 1 out of 3 or 4 times in my environment. Restarting the broker allows the command to complete successfully.

    Description

      When running a broker with the default property file-base login module with the default karaf jaas realm, adding a new user and corresponding authorizationEntry sometimes results in failed authorization that persists untile the broker is restarted. For example, adding the authorization for

                          <authorizationEntry topic="test.input.>" read="testadm" write="testadm" admin="admin"/>
                          <authorizationEntry topic="test.>" read="test1" write="test1" admin="admin"/>
      

      to the existing plugin configuration:

              <plugins>
                  <runtimeConfigurationPlugin checkPeriod="60000" />
                  <jaasAuthenticationPlugin configuration="karaf" />
                  <authorizationPlugin>
                    <map>
                      <authorizationMap groupClass="org.apache.karaf.jaas.boot.principal.RolePrincipal">
                        <!-- manager,viewer,Operator,Maintainer,Deployer,Auditor,Administrator,SuperUser,admin,User -->
                        <authorizationEntries>
                          <authorizationEntry queue=">" read="manager,viewer,Operator,Maintainer,Deployer,Auditor,Administrator,SuperUser,admin" write="manager,Operator,Maintainer,Deployer,Auditor,Administrator,SuperUser,admin" admin="manager,Operator,Maintainer,Deployer,Auditor,Administrator,SuperUser,admin"/>
                          <authorizationEntry topic="test.input.>" read="testadm" write="testadm" admin="admin"/>
                          <authorizationEntry topic="test.>" read="test1" write="test1" admin="admin"/>
                          <authorizationEntry topic=">" read="manager,viewer,Operator,Maintainer,Deployer,Auditor,Administrator,SuperUser,admin" write="manager,Operator,Maintainer,Deployer,Auditor,Administrator,SuperUser,admin" admin="manager,Operator,Maintainer,Deployer,Auditor,Administrator,SuperUser,admin"/>
                          <authorizationEntry topic="ActiveMQ.Advisory.>" read="manager,viewer,Operator,Maintainer,Deployer,Auditor,Administrator,SuperUser,admin,User" write="manager,viewer,Operator,Maintainer,Deployer,Auditor,Administrator,SuperUser,admin,User" admin="manager,viewer,Operator,Maintainer,Deployer,Auditor,Administrator,SuperUser,admin,User" />
                        </authorizationEntries>
                        <tempDestinationAuthorizationEntry>
                          <tempDestinationAuthorizationEntry read="manager,viewer,Operator,Maintainer,Deployer,Auditor,Administrator,SuperUser,admin" write="manager,Operator,Maintainer,Deployer,Auditor,Administrator,SuperUser,admin" admin="manager,Operator,Maintainer,Deployer,Auditor,Administrator,SuperUser,admin"/>
                        </tempDestinationAuthorizationEntry>
                      </authorizationMap>
                    </map>
                  </authorizationPlugin>
              </plugins>
      

      while adding the user:

      testadm=testadm,testadm,admin
      

      Sometimes results in failures like:

      Error executing command: User testadm is not authorized to create: topic://ActiveMQ.Advisory.Connection
      

      Restarting the broker with no other changes resolves the errors and the producer is able to publish. Without restarting, the error seems to persist, even after waiting several minutes and producing fails.

      Attachments

        Activity

          People

            gtully@redhat.com Gary Tully
            rhn-support-dhawkins Duane Hawkins
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: