Why does the "read" permission level allow users to purge the queue?

[Ryan Zink]

I am running RabbitMQ instances in an environment where we anticipate having a kiosk of sorts viewing the management plugin in a browser. We have created a new user for this kiosk, which has monitoring access and only read permissions to the "/" vhost. We have confirmed that this is working as expected, that users can't delete queues, etc. However I was surprised that read users can purge the queue (and I saw that is documented here: https://www.rabbitmq.com/access-control.html). 

What is the rationale for this? I guess I understand from a messaging perspective that a read user should be able to read all messages (equivalent to a purge) but it makes using the read permission in our use case somewhat limited. Is there some other way to restrict which actions the management plugin users can delete?

Thanks,

Ryan

[Michael Klishin]

This decision dates many years back but yes, I think “purge” can be treated as
“read all” by some. I personally would consider reviewing it for 3.6.0.

There is no way to restrict access beyond what’s in the table linked.
If the kiosk is going to use HTTP API, however, you can run Nginx (or similar)
in front of it and try limiting access to the purge operation endpoint:

DELETE /api/queues/{vhost} /{name}/contents
--
MK

Staff Software Engineer, Pivotal/RabbitMQ

[Ryan Zink]

I guess then the problem might be best related to the rabbitmq-management plugin more so than the server itself. The lowest level access to the management plugin, "management", when given only read access to the vhost, will prevent deletion of the queues but will not prevent purging the queues. 

Given our use case, is there a way to create another, truly "read-only" user that doesn't have the ability to perform destructive actions (maybe by not having the purge button, etc.)? Is something like that on the roadmap at all?

[full19...@gmail.com]

[full19...@gmail.com]

Ryan, I have run into the same issue when trying to setup a 'read-only' user. Did you ever find a solution? If so, [please share...it would be greatly appreciated!

Thanks

AlonnaG

[Ryan Zink]

Hi Alonna,

Unfortunately, since it's a design decision we didn't come up with a good solution to this. I suppose you could create a wrapper for the management plugin using the management API and obfuscate the ability to delete or purge messages, but it wasn't something we wanted to invest time in.

Ryan