Preflight capability check returns 403 for nonexistent mounts, even with a root token

[kberzinch]

Describe the bug

Reads from /sys/internal/ui/mounts/... for a path that does not exist always returns a 403, even when authenticated with a root token.

To Reproduce

Steps to reproduce the behavior:

$ vault server -dev -dev-root-token-id=roottoken

# in a separate shell
$ export VAULT_ADDR='http://127.0.0.1:8200'
$ export VAULT_TOKEN=roottoken
$ vault read sys/internal/ui/mounts/nonexistent
Error reading sys/internal/ui/mounts/nonexistent: Error making API request.

URL: GET http://127.0.0.1:8200/v1/sys/internal/ui/mounts/nonexistent
Code: 403. Errors:

* preflight capability check returned 403, please ensure client's policies grant access to path "nonexistent/"

Expected behavior

A 404 error is returned.

Environment:

• Vault Server Version (retrieve with vault status): 1.7.0
• Vault CLI Version (retrieve with vault version): 1.7.0
• Server Operating System/Architecture: Ubuntu 20.04 on Intel

Vault server configuration file(s):

Default -dev config

Additional context

This is largely copied from concourse/concourse#6896.

[sgmiller]

This is actually intended behavior. The error message is generically "permission denied" but the reason is so that the response when you try to read a mount that doesn't exist with or without valid permissions is identical to trying to read one that does exist with or without said permissions.

In other words, we're avoiding leaking any information about what mounts exist or don't exist to an attacker trying to brute force the list of mounts. That said I agree the message is pretty unhelpful.

This changed here: #10650

[kberzinch]

So there's no way for me to construct a policy such that this type of call would return a 404 instead of a 403? That seems unintuitive.

[sgmiller]

That's currently correct, and yeah, it's a bit of a mind-bender.