Capability "deny" does not take precedence over "list"

[toorog]

Describe the bug

The token is allowed to list a sub-path while at the same time a restriction is in place which does not allow it to do so.

To Reproduce
Steps to reproduce the behavior:
Add the following policy to a new token:

path "secret/*" {
   capabilities=["list"]
}
path "secret/notvisible" {
  capabilities=["deny"]
}

Expected behavior

1. Token is able able to list all resources in secret
2. Token is not allowed to list the content of secret/notvisible as the documentation states that the more specific path takes precedence.

Environment:

• Vault Server Version (retrieve with vault status): 0.10.4
• Vault CLI Version (retrieve with vault version): 0.10.4
• Server Operating System/Architecture: Docker Container

Vault server configuration file(s):

{"ui":"true","listener":[{"tcp":{"address":"0.0.0.0:8200","tls_disable":"1"}}],"backend":{"file":{"path":"/vault/file"}},"default_lease_ttl":"168h","max_lease_ttl":"720h"}

[jefferai]

Listing always operates on prefixes, so the correct path to deny listing would be secret/notvisible/. Or, assuming you don't want any operation anywhere down that path, secret/notvisible* should work.

[treber-fool]

I wanted to add a note to this regarding something I discovered this evening using KV2.

Going back to the example above, which mimicked a problem I was having pretty much exactly...

path "secret/*" {
  capabilities=["list"]
}
path "secret/notvisible" {
  capabilities=["deny"]
}

That will not actually work as described in KV2, nor will it work as I'd expect with the documented KV2 changes to policies. This lead to some frustrating troubleshooting trying to figure out exactly what policy would work to achieve this behavior. Per those documented changes, we now have a /data/ prefix. As such, I would have expected to have had to do the following to make the policy above continue to work in KV2:

path "secret/data/*" {
   capabilities=["list"]
}
path "secret/data/notvisible" {
  capabilities=["deny"]
}

However, doing that actually causes a permissions error when trying to access ANYTHING under the secret path. What does work, oddly, is the following:

path "secret/*" {
   capabilities=["list"]
}
path "secret/data/notvisible" {
  capabilities=["deny"]
}

I certainly get why you would need the data prefix in the deny policy. I just don't really understand why it causes a permissions error when used in the list policy? It seems like it should be needed in both policies or at the least, that it would still work if it were in the list policy (vs failing with permission denied).

[jefferai]

It's because as noted in the ACL Rules section, listing requires permissions on secret/metadata/ which is covered by secret/* but not by secret/data/*.

[BartDrown]

It's because as noted in the ACL Rules section, listing requires permissions on secret/metadata/ which is covered by secret/* but not by secret/data/*.

Yes, it need that permission, but granting it, makes every path and file listed, with no regards for any 'deny' policy in subpaths.
Deny policy just does not work on paths (at least for me), no clue why.