Surprising permission checks performed when adding a Shovel

[inikulshin]

Hi,

Here are the logs we get (RabbitMQ 3.7.24, acting user is 5697bfdf-b663-441e-9078-ae9567c11cb6)

11:18:05 TRC:   Upserting shovel nasuni.imcoming.shovel on vhost / {
11:18:05 INF:    Invoking PUT: http://localhost:15672/api/parameters/shovel/%2f/nasuni.imcoming.shovel with json:
{"value":{"dest-exchange":"vsb.topic=nasuni.incoming.ex","dest-uri":"amqp:///%2f?heartbeat=900","src-queue":"nasuni.incoming.q","src-uri":"amqp://VaronisOwner@/nasuni?heartbeat=900"}}
11:18:05 ERR:    Bad request: Validation failed

user "5697bfdf-b663-441e-9078-ae9567c11cb6" may not connect to vhost "nasuni"

I don't understand why is this access check performed at all.

5697bfdf-b663-441e-9078-ae9567c11cb6 should have access to vhost '/' (to create shovel)
guest should have access to vhost '/' (dest-exchange)
VaronisOwner should have access to vhost 'nasuni' (src-queue)

I'm not sure the last 2 should be validated during PUT, but AFAIU, the failed access check shouldn't be performed.

[michaelklishin]

There are two sides to every Shovel: the source and destination ones. As such, both sides are validated, including their respective URIs which for the 2nd user include

amqp://VaronisOwner@/nasuni

It's not clear from your log how the user 5697bfdf-b663-441e-9078-ae9567c11cb6 is involved. It may be the acting user but we have no evidence of that. Consider providing an executable way of reproducing.

Whether the acting user should have access to either source or destination depends on who you ask. Such fine-grained user separation is admirable but rare to see: quite often the declaring user is also used to connect to either source or destination.

[inikulshin]

@michaelklishin thanks.

The 5697bfdf-b663-441e-9078-ae9567c11cb6 user's credentials are provided to Invoke-RestMethod -Method PUT...

It's not clear (to me), which user should be used for source and destination queues creation.
What happens if any (or both) of src/dest queues is remote (on different host) and can't be accessed with acting user?
Is queue creation step skipped or URI's user is used?

P.S.
Also, AFAIR the existing shovels know to recreate deleted src/dest queues. At that time the user, who created shovel, can't be used, even if remembered somehow (in our case it was temporary user which doesn't exist anymore).
That means, queues are created by URI's users, and the performed access check is redundant.

[michaelklishin]

So 5697bfdf-b663-441e-9078-ae9567c11cb6 is the user that is used to authenticate with the HTTP API?

Currently, Shovel checks permissions for the acting user as well. This is likely to be more consistent with other endpoints, and because a separate user is rarely used from both source and destinations (e.g. Shovels are very frequently declared on one or the other side).

@kjnilsson do you remember what the thinking was during the multi-protocol Shovel redesign?

[inikulshin]

Yes, 5697bfdf-b663-441e-9078-ae9567c11cb6 is used to authenticate with the HTTP API.

separate user is rarely used from both source and destinations

You mean, you know to check permissions for URI's user, but you do it only for either source or destination, never for both?
And only during shovel creation - because during missing queue recreation by existing shovel URI's user is used.