Subscribe possible without permission

HiveMQ Community Edition
1

Hi,

I just installed HiveMQ CE 2020.5 with the following extensions:

  • File RBAC
  • MQTT Message Log
  • Deny Root Wildcard Subscriptions

The content of credentials.xml for the RBAC extension is

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<file-rbac>
    <users>
        <user>
            <name>user1</name>
            <password>pass1</password>
            <roles>
                <id>role1</id>
            </roles>
        </user>
    </users>
    <roles>
        <role>
            <id>role1</id>
            <permissions>
                <permission>
                    <topic>topic/data</topic>
                    <activity>PUBLISH</activity>
                </permission>
            </permissions>
        </role>
    </roles>
</file-rbac>

After reading the documentation I would have expected to get a NOT_AUTHORIZED if I try to subscribe to topic/data. But I can subscribe and receive messages.

Subscribe:

$ mqtt sub -t topic/data -h localhost -p 1883 -u user1 -pw pass1
Hello World...

Publish:

$ mqtt pub -t topic/data -m "Hello World..." -h localhost -p 1883 -u user1 -pw pass1

The server log for the subscribe:

INFO  - Received CONNECT from client 'hmq_A0jix_5_272f4cb78ad7ece55b955844891d6ea8': Protocol version: 'V_5', Clean Start: 'true', Session Expiry Interval: '9223372036854775807'
INFO  - Sent CONNACK to client 'hmq_A0jix_5_272f4cb78ad7ece55b955844891d6ea8': Reason Code: 'SUCCESS', Session Present: 'false'
INFO  - Received SUBSCRIBE from client 'hmq_A0jix_5_272f4cb78ad7ece55b955844891d6ea8': Topics: { [Topic: 'topic/data', QoS: '2'] }
INFO  - Sent SUBACK to client 'hmq_A0jix_5_272f4cb78ad7ece55b955844891d6ea8': Suback Reason Codes: { [Reason Code: 'GRANTED_QOS_2'] }

When I define SUBSCRIBE as the allowed acitivity in credentials.xml the publish gets rejected as expected.

I could also reproduce this behavior with a custom SimpleAuthenticator without the RBAC extension. So it is not an issue with the extension itself. But is this an issue or is it expected behavior?

Thanks for any help.

2

Hello @chrherrmann,

I can confirm this behaviour. I could narrow it down to the combination of the RBAC and Deny Wildcard extension.


You can see that the Deny Wildcard extension authorizes successfully if the subscription is not a root wildcard, which are in conflict with the default permissions that the RBAC extension uses.

The workaround is to not use the deny wildcard extension (which is redundant in your case, because with your credentials.xml you already can’t subscribe to root wildcard with the RBAC extension).

Greetings,
Michael

3

Hi Michael,

thanks for looking into this. It makes sense that the two extensions interfere with each other. Although it is somewhat unexpected as the Deny Wildcard extension could probably be modified to work with other authorization extensions (priority, nextExtensionOrDefault(), etc.). But as you said, it is redundant if it is combined with a whitelist authorization extension.

Thanks for the quick reply!