ACL deny by server on Publish still produces Success in client (python)

[nipil]

Bug Description

A python client publishing to a topic denied by ACL still gets a '0/success' reason_code

Reproduction

• Clone https://gist.github.com/nipil/75e9d7cd4edbf1ae8024f0507cc7dc62
• Create .devcontainer/ folder and move devcontainer.json (gists do not allow folders)
• Open folder as DevContainer in VS code (or similar)
• Open a terminal and run python3 test.py

Environment

• Python version: 3.11
• Library version: paho-mqtt 2.1
• Operating system (including version): docker/linux
• MQTT server : mosquitto 2.0.21
• server authentication : user foo password foo

Logs

Publishing to foo by authenticated foo user : expected "Success", got "Success"

CLIENT : Sending PUBLISH (d0, q0, r0, m1), 'b'foo'', ... (3 bytes)
SERVER: Received PUBLISH from auto-03B09290-F39A-6397-1F35-9F5F045BD652 (d0, q0, r0, m0, 'foo', ... (3 bytes))
CLIENT : on_publish mid=1 reason_code=0/Success

Publishing to bar by authenticated foo user : expected anything but "Success", yet still got "Success"

CLIENT: Sending PUBLISH (d0, q0, r0, m2), 'b'bar'', ... (3 bytes)
SERVER: Denied PUBLISH from auto-03B09290-F39A-6397-1F35-9F5F045BD652 (d0, q0, r0, m0, 'bar', ... (3 bytes))
CLIENT: on_publish mid=2 reason_code=0/Success

In case this is a normal/accepted/de-facto behaviour, please provide some insight as to :

• where this is communicated in the documentation or specification
• how it could be changed so that clients are actually notified of denyed publish

Thanks in advance

[JamesParrott]

Hi there, sorry this has been so long. Does this issue still occur with MQTT5 and QoS1? https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#_Toc3901124 We ought to pass on 0x80 and 0x87 errors to the client code

In 3.1.1 I'm not sure what we can do within the spec: https://docs.oasis-open.org/mqtt/mqtt/v3.1.1/errata01/os/mqtt-v3.1.1-errata01-os-complete.html#_Toc442180858

[JamesParrott]

After thinking about this again, there's certainly no magical way we can assist attackers of semi-open brokers that only support MQTT v3.1.1. And users such as foo and bar in the Gist example (see ACL below), with the permission to subscribe to that topic have a simple work around available of course: subscribe to it themselves as well, and do something if they don't recognise what they published after some period of time.

Beyond exposing MQTTv5 QoS 1 reason codes (if Paho doesn't already), I don't think there's anything else we can do within the protocol. Silent failure is simply one possible course of action, that MQTTv3 or QoS0 Brokers are free to choose to take, in response to ACL violations.

Another potential work around for Broker owners running Mosquitto, could be to find a Dynamic Security Plug-in (or write one like a C-extension) that e.g. kicks such unauthorised would-be publishers, an. But that's way out of scope for Paho.MQTT.

acl.conf

user foo
topic write foo
topic read foo
topic read bar

user bar
topic write bar
topic read foo
topic read bar