Response from wildcard resolution vs specific index access #29918
Description
Original comment by @jaymode:
The current authorization behavior (5.1.1 RC) is a bit different when a user requests values for indices that do not exist or they are not authorized to see. For example, consider the following table:
| Authorized | Specific Index (exists) | Specific Index (nonexisting) | Wildcard (exists) | Wildcard (nonexisting) |
|---|---|---|---|---|
| Yes | 200 | 404 | 200 | 200 |
| Yes (no security) | 200 | 404 | 200 | 200 |
| No (no indices permissions) | 403 | 403 | 403 | 403 |
| No (indices permissions) | 403 | 403 | 200 | 200 |
The action used here was a search request and nothing with indices options was modified. The first row is from a user with superuser privileges. The third row user only has cluster privileges and the fourth row user cluster monitor indices privileges to a non-existing index.
Another example is the cat indices API, which uses a mix of cluster and index actions:
| Authorized | Specific Index (exists) | Specific Index (nonexisting) | Wildcard (exists) | Wildcard (nonexisting) |
|---|---|---|---|---|
| Yes | 200 | 404 | 200 | 200 |
| Yes (no security) | 200 | 404 | 200 | 200 |
| No (no indices permissions) | 403 | 403 | 403 | 403 |
| No (indices permissions) | 403 | 404 | 200 | 200 |
The one difference is when a specific index is requested but doesn't exist. I think we get the 404 because of the indices options that the API uses (maybe @javanna can confirm).
We should make the third and fourth row behavior consistent.
The other item I'd like to consider is when a user is not authorized to an index then we would show a 404 regardless of if the index exists or not.