HTTP API: GET /api/queues/{vhost} requests logs a debug message saying that access to certain virtual hosts is prohibited

[clude86]

Describe the bug

When calling /api/queues/myvhost for a specific vhost myvhost, RabbitMQ attempts to access all other existing vhosts. If the user does not have permissions on those vhosts, the following error occurs:

"[debug] Access to vhost '/' refused for user 'myuser'

Expected behavior:
The API should only query the requested vhost (myvhost). Other vhosts must not be accessed.

Actual behavior:

• The API tries to access all vhosts, even those the user cannot access, causing unnecessary errors.

• Good: The response of /api/queues/myvhost contains only the requested vhost. The returned data itself is correct.

Reproduction steps

1. Create multiple vhosts, e.g., /, myvhost, other_vhost.
2. Create a user myuser with access only to myvhost.
3. Call /api/queues/myvhost with myuser.
4. Observe the access_refused error for other vhosts. (debug mode enabled!)

Expected behavior

The API should only query the requested vhost (myvhost). Other vhosts must not be accessed.

Additional context

No response

[michaelklishin]

@clude86 it's not uncommon for various API endpoints to filter virtual hosts accessible to the user.

You haven't provided any evidence or steps to reproduce. Not even what RabbitMQ version is used. We do not guess in this communities.

[michaelklishin]

Here is the API handler module in question.

Indeed, it filters out what virtual hosts are available to the user because the same endpoint handles GET /api/queues without any {vhost}.

The message in question is a debug log entry, not an error.

For any meaningful further investigation we need

1. RabbitMQ version details
2. An executable way to reproduce (a script that creates some virtual hosts, users, permissions using CLI tools and then uses curl to drive GET /api/queues/{vhost}

A debug log message is not a bug by any stretch.

[clude86]

Thanks for your reply!

You’re right — my initial description was too abstract.
I already mentioned some steps earlier, but to make it fully reproducible, I’ve prepared a complete Docker-based example below.
This setup allows you to see the Access to vhost '/' refused for user 'myuser' message by enabling debug logging via rabbitmqctl.

Environment:
RabbitMQ 4.1.5

Reproduction Example (Docker)

1. docker-compose.yml

services:
  rabbit:
    image: rabbitmq:4.1.5-management
    container_name: rabbit-api-repro
    environment:
      RABBITMQ_DEFAULT_USER: admin
      RABBITMQ_DEFAULT_PASS: admin
      RABBITMQ_LOGS: "-"
    ports:
      - "15672:15672"
      - "5672:5672"

2. Start RabbitMQ

docker compose up -d

Wait until the broker is ready:

docker logs -f rabbit-api-repro

3. Enable debug logging

docker exec -it rabbit-api-repro rabbitmqctl set_log_level debug

4. Create multiple vhosts and a user

# Create vhosts
curl -u admin:admin -X PUT http://localhost:15672/api/vhosts/%2F
curl -u admin:admin -X PUT http://localhost:15672/api/vhosts/myvhost
curl -u admin:admin -X PUT http://localhost:15672/api/vhosts/othervhost

# Create a user with management access (so it can use the HTTP API)
curl -u admin:admin -X PUT http://localhost:15672/api/users/myuser \
  -H "Content-Type: application/json" \
  -d '{"password":"mypass","tags":"management"}'

# Grant permissions only on myvhost
curl -u admin:admin -X PUT http://localhost:15672/api/permissions/myvhost/myuser \
  -H "Content-Type: application/json" \
  -d '{"configure":".*","write":".*","read":".*"}'

5. Create a test queue

curl -u myuser:mypass -X PUT http://localhost:15672/api/queues/myvhost/testqueue \
  -H "Content-Type: application/json" \
  -d '{}'

6. Trigge the issue / improvement

curl -u myuser:mypass http://localhost:15672/api/queues/myvhost

In the RabbitMQ logs (docker logs rabbit-api-repro), with debug logging enabled, you will see:

[debug] <0.909.0>   {amqp_error,not_allowed,
[debug] <0.909.0>        "access to vhost '/' refused for user 'myuser'",
[debug] <0.909.0>     none}}
[debug] <0.909.0> rabbit_access_control:check_vhost_access result: {'EXIT',
[debug] <0.909.0>    {amqp_error,not_allowed,
[debug] <0.909.0>     "access to vhost 'othervhost' refused for user 'myuser'",
[debug] <0.909.0>      none}}
[debug] <0.909.0> rabbit_access_control:check_vhost_access result: {'EXIT',
[debug] <0.909.0>       {amqp_error,not_allowed,
[debug] <0.909.0>         "access to vhost '/' refused for user 'myuser'",
[debug] <0.909.0>        none}}
[debug] <0.909.0> rabbit_access_control:check_vhost_access result: {'EXIT',
[debug] <0.909.0>     {amqp_error,not_allowed,
[debug] <0.909.0>      "access to vhost 'othervhost' refused for user 'myuser'",
[debug] <0.909.0>    none}}

This happens even though the request was only for /api/queues/myvhost.

Expected Behavior

• The endpoint /api/queues/myvhost should only query the requested vhost (myvhost).
• No access checks or queries to / or other vhosts should occur.
• It would be better if the API directly accessed the given vhost instead of trying other vhosts first to discover that the user has no permissions. Accessing unrelated vhosts unnecessarily leads to confusing log entries and potential errors.

[lukebakken]

Yep, I can reproduce this - https://github.com/lukebakken/rabbitmq-server-14923

@clude86 just FYI, repos on GitHub are free, so that's, by far, the easiest way to provide artifacts, scripts, docs, etc when you report an issue, rather than lines in a comment.

redbug-provided stack trace

% 00:39:13 <0.590.0>(dead)
% rabbit_access_control:check_vhost_access({user,<<"myuser">>,
      [management],
      [{rabbit_auth_backend_internal,#Fun<rabbit_auth_backend_internal.3.18474459>}]}, <<"myvhost">>, {ip,{127,0,0,1}}, #{})
%   rabbit_mgmt_util:'-list_login_vhosts_names/2-lc$^0/1-0-'/3
%   rabbit_mgmt_util:filter_vhost/3
%   rabbit_mgmt_wm_queues:to_json/2
%   cowboy_rest:call/3
%   cowboy_rest:set_resp_body/2
%   cowboy_rest:upgrade/4
%   cowboy_stream_h:execute/3
%   cowboy_stream_h:request_process/3
%   proc_lib:init_p_do_apply/3

% 00:39:13 <0.590.0>(dead)
% rabbit_access_control:check_vhost_access/4 -> ok

% 00:39:13 <0.590.0>(dead)
% rabbit_access_control:check_vhost_access({user,<<"myuser">>,
      [management],
      [{rabbit_auth_backend_internal,#Fun<rabbit_auth_backend_internal.3.18474459>}]}, <<"/">>, {ip,{127,0,0,1}}, #{})
%   rabbit_mgmt_util:'-list_login_vhosts_names/2-lc$^0/1-0-'/3
%   rabbit_mgmt_util:'-list_login_vhosts_names/2-lc$^0/1-0-'/3
%   rabbit_mgmt_util:filter_vhost/3
%   rabbit_mgmt_wm_queues:to_json/2
%   cowboy_rest:call/3
%   cowboy_rest:set_resp_body/2
%   cowboy_rest:upgrade/4
%   cowboy_stream_h:execute/3
%   cowboy_stream_h:request_process/3
%   proc_lib:init_p_do_apply/3

% 00:39:13 <0.590.0>(dead)
% rabbit_access_control:check_vhost_access/4 -> {exit,
                                                 {amqp_error,not_allowed,
                                                  "access to vhost '/' refused for user 'myuser'",
                                                  none}}

% 00:39:13 <0.590.0>(dead)
% rabbit_access_control:check_vhost_access({user,<<"myuser">>,
      [management],
      [{rabbit_auth_backend_internal,#Fun<rabbit_auth_backend_internal.3.18474459>}]}, <<"othervhost">>, {ip,{127,0,0,1}}, #{})
%   rabbit_mgmt_util:'-list_login_vhosts_names/2-lc$^0/1-0-'/3
%   rabbit_mgmt_util:'-list_login_vhosts_names/2-lc$^0/1-0-'/3
%   rabbit_mgmt_util:filter_vhost/3
%   rabbit_mgmt_wm_queues:to_json/2
%   cowboy_rest:call/3
%   cowboy_rest:set_resp_body/2
%   cowboy_rest:upgrade/4
%   cowboy_stream_h:execute/3
%   cowboy_stream_h:request_process/3
%   proc_lib:init_p_do_apply/3

% 00:39:13 <0.590.0>(dead)
% rabbit_access_control:check_vhost_access/4 -> {exit,
                                                 {amqp_error,not_allowed,
                                                  "access to vhost 'othervhost' refused for user 'myuser'",
                                                  none}}

[lukebakken]

The code that checks vhost access is hairy. Looks like a good first place to improve is rabbit_web_dispatch_access_control:list_login_vhosts_names/2. When called from user_matches_vhost/2, we already know which vhost we're checking, so there's no need to enumerate them all.

[lukebakken]

Well, let's see what CI thinks about this - #14931

[clude86]

Thanks a lot, @lukebakken — I really appreciate the quick response and confirmation!
Also, thanks for the helpful feedback — that makes perfect sense.
Next time I’ll make sure to put the artifacts, scripts, and docs into a dedicated repository instead of inline comments.

[lukebakken]

@clude86 - OK, the PR is merged and the changes will be in the next RabbitMQ release. Please check in your environment and report back here, we'd appreciate it. Thanks again for taking the time to report this behavior.

[michaelklishin]

Addressed by #14931 contributed by @lukebakken.

Note that besides a tiny efficiency gain, there are no practical gains here for those who run with log severity levels starting with info (without debug logging enabled).