Issue with subscription ACL pattern and logginglients

Mosquitto MQTT Broker
1

I have a working system using Mosquitto 2.0.13. There are two connection types - client and engine
both types use TLS client certificates and use the same listener on 8883. Because of legacy code the clients are not logging on (yet) so the listener is set to allow anonymous.

I have been doing some basic penetration testing and found a concern but don’t know if this is a problem or not.

My ACL is set up to allow anonymous clients the ability to read and write client patterns
pattern read /pgn/%c/cmd
pattern write /pgn/%c/data

I connect as client1 and tried to publish as client2 and log showed ‘denied PUBLISH’ - Good, that is what I want.
But, client2 ( or anyone) seems to be able to subscribe to ANY topic ( even /# ) without an error in the log . Log shows ‘Received SUSCRIBE from client1 /# (Qos 1)’. It does not appear that the bad subscribe is working in that the client is not receiving more data than it should after the extra subscribe but I am worried that the log suggests the subscribe has been approved.

Any idea what is happening?

Here are config and ACL
config


per_listener_settings true

allow_anonymous false
connection_messages true

# uncomment logdest stdout  for troubleshooting to see live logs on screen
#log_dest stdout 
log_type debug
log_type error
log_type warning
log_type notice
log_type information


listener 8883
allow_anonymous true
acl_file /etc/mosquitto/conf.d/newacl.txt
password_file /etc/mosquitto/conf.d/passwords.txt
cafile /etc/mosquitto/ca_certificates/ca.crt
certfile /etc/mosquitto/certs/server.crt
keyfile /etc/mosquitto/certs/server.key
require_certificate true
tls_version tlsv1.2

ACL

#user clientdevice  ( commented out so anonymous)
pattern read /pgn/%c/cmd
pattern write /pgn/%c/data

# user engine gets to read and write all topics
user engine
topic readwrite /pgn/#
topic readwrite $SYS/#
2

Hi,

The ACL file doesn’t currently stop subscriptions. It applies the rules for read at the point the client is due to receive a message. You’ve said that the client doesn’t receive the messages, so you can rest assured that it’s working as expected.

Regards,

Roger

3

Roger ,
Thanks for the clarification but this behavior does appear to be both:

  1. Counterintuitive - I can’t think of any other legitimate subscription mechanism of any type or media that allows me to subscribe to something without any intention of ever delivering anything!

  2. Inefficient - why check every subscriber’s ACL for every brokered message instead of checking just once at subscription and disallowing the subscription?

If there really is a good reason to do it this way, I suggest the following modification to logging to make the behavior clear to users:

Upon Subscription, additionally perform the ACL check ( perhaps with dummy data) and if it fails, output a different log message.
e.g.
Received SUSCRIBE from client1 for /# (Qos 1)’ - WARNING data will not be delivered - violates ACL newacl.txt line line 2

Bill

4

Thanks for the feedback. To respond to your points, yes it may be unexpected that the subscription succeeds, but the end result that you asked for is achieved. It is easier to come up with a reliable way to check a publish topic (which has no wildcards) against an ACL topic filter than is it to check a subscribe topic filter (which has wildcards) against an ACL topic filter. At the time the file based ACLs were implemented I took the decision to just focus on publish messages. I have code now for checking subscriptions against ACLs, but adding more features to the acl files hasn’t been a priority. I certainly wouldn’t want to change the behaviour of the existing features, it would have to be an addition.

Regards,

Roger