Qpid
  1. Qpid
  2. QPID-3892

ACLs shall support full regular expressions in property values

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.14
    • Fix Version/s: 0.19
    • Component/s: C++ Broker
    • Labels:

      Description

      Currently ACL syntax supports in a property value either direct match ("name=RequestQueue") or a substring match ("name=tmp.*").

      That is not sufficient when authorizing access to topics. One particular example: amq.topic exchange receives messages with keys usa.sports, usa.news, europe.sports and europe.news. Currently we can not authorize access just to topics *.sports and to usa. *

      As there exist different use cases where regular expressions are required in a, it is meaningful to support (full) regular expressions in ACL property values.

      Since qpid C++ broker already relies on boost libraries a lot, I suggest (in a patch proposed) using boost::regex library.

      I tested the attached patch on Fedora, not sure if other Linux distributions are familiar with the change in Makefile.am.

        Activity

        Hide
        Pavel Moravec added a comment -

        A comment to the description (did not know formatting syntax that expanded asterisks):

        Current ACLs can't authorize just to <anything>.sports and to usa.<anything>

        Show
        Pavel Moravec added a comment - A comment to the description (did not know formatting syntax that expanded asterisks): Current ACLs can't authorize just to <anything>.sports and to usa.<anything>
        Hide
        Chuck Rolke added a comment -

        Pavel Moravec has suggested changing the C++ Broker ACL syntax to use regular expressions. I think this is a great idea as it addresses a missing functionality in the current ACL wildcard syntax. I would like to elaborate on his proposal.

        Plugging in his suggestion is not so straight forward:
        1. It breaks the current ACL specifications.
        name=tmp* would match "tm", "tmp", and "tmpp" but not "tmp2".
        2. It requires a regex library such as boost::regex.

        I propose to include regular expressions in the ACL property values match by:

        1. Adding new keyword to the ACL file to control regex matching.

        matchregex on
        matchregex off
        
        • This defaults to off and current ACL files are processed exactly as before.
        • Whenever 'matchregex on' happens in the ACL file then subsequent rules are processed with the property value strings being regex match strings and not plain text strings.
        • Regex matching can be turned off again with 'matchregex off'.

        2. Boost_regex is added as a dependency for acl.so. I know that there has been activity not so long ago to get rid of boost_regex. However the need for more complex property value match specifications is acute.

        My GCC 4.6.2 has a <tr1/regex> for compilation but it does not link so that's no good. Are there better alternatives?

        Example:

        An enterprise customer may wish to use:

        acl allow dev bind exchange name=Price routingkey=Price.*.*.* queuename=TempQueue*
        

        This is impossible to specify today. With regex processing the same customer could use:

        matchregex on
        acl allow dev bind exchange name=Price routingkey=Price\..*\..*\..* queuename=TempQueue.*
        

        I'll complete these changes and put the up to Review Board.

        -Chuck

        Show
        Chuck Rolke added a comment - Pavel Moravec has suggested changing the C++ Broker ACL syntax to use regular expressions. I think this is a great idea as it addresses a missing functionality in the current ACL wildcard syntax. I would like to elaborate on his proposal. Plugging in his suggestion is not so straight forward: 1. It breaks the current ACL specifications. name=tmp* would match "tm", "tmp", and "tmpp" but not "tmp2". 2. It requires a regex library such as boost::regex. I propose to include regular expressions in the ACL property values match by: 1. Adding new keyword to the ACL file to control regex matching. matchregex on matchregex off This defaults to off and current ACL files are processed exactly as before. Whenever 'matchregex on' happens in the ACL file then subsequent rules are processed with the property value strings being regex match strings and not plain text strings. Regex matching can be turned off again with 'matchregex off'. 2. Boost_regex is added as a dependency for acl.so. I know that there has been activity not so long ago to get rid of boost_regex. However the need for more complex property value match specifications is acute. My GCC 4.6.2 has a <tr1/regex> for compilation but it does not link so that's no good. Are there better alternatives? Example: An enterprise customer may wish to use: acl allow dev bind exchange name=Price routingkey=Price.*.*.* queuename=TempQueue* This is impossible to specify today. With regex processing the same customer could use: matchregex on acl allow dev bind exchange name=Price routingkey=Price\..*\..*\..* queuename=TempQueue.* I'll complete these changes and put the up to Review Board. -Chuck
        Hide
        Chuck Rolke added a comment -

        Fixed by r1361678 and r1362014.

        Note that the fix does not use regex. Instead Acl code now uses the same Topic Exchange match code that the broker runtime uses. This avoids introducing new syntax (regex) in the Acl file and lets it use naturally expressed topic exchange syntax. Also this fix adds no new module to any distributions.

        Show
        Chuck Rolke added a comment - Fixed by r1361678 and r1362014. Note that the fix does not use regex. Instead Acl code now uses the same Topic Exchange match code that the broker runtime uses. This avoids introducing new syntax (regex) in the Acl file and lets it use naturally expressed topic exchange syntax. Also this fix adds no new module to any distributions.

          People

          • Assignee:
            Chuck Rolke
            Reporter:
            Pavel Moravec
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development