-
Notifications
You must be signed in to change notification settings - Fork 25k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
403 for no index permission from _cat/indices call #37190
Comments
This is by design: empty indices are considered as a wildcard expression (same as specifying *), which is expanded to all the indices that the current user is authorized for. When specifying a concrete index though, you will get an error back like you noticed. I am pretty sure that this is documented somewhere, but I can't seem to find where anymore. Maybe somebody from @elastic/es-security can chime in. |
@javanna This behavior is asymmetrical though. Users can see indices that they don't have permissions for when they don't specify an index list. Seems to me that those indices should just be filtered out and then the behavior would be more consistent. |
@bmcconaghy I see what you mean, I agree with you. |
Pinging @elastic/es-core-features |
I agree as well. I think the prob is in elasticsearch/server/src/main/java/org/elasticsearch/rest/action/cat/RestIndicesAction.java Line 126 in 9ceb218
|
Thanks for taking a look at this @albertzaharovits ! |
This changes the output of the `_cat/indices` API with `Security` enabled. It is possible to only display the index name (and possibly the index health, depending on the request options) but not its stats (doc count, merges, size, etc). This is the case for closed indices which have index metadata in the cluster state but no associated shards, hence no shard stats. However, when `Security` is enabled, and the request contains wildcards, **open** indices without stats are a common occurrence. This is because the index names in the response table are picked up directly from the cluster state which is not filtered by `Security`'s _indexNameExpressionResolver_, unlike the stats data which is populated by the indices stats API which does go through the index name resolver. This is a bug, because it is circumventing `Security`'s function to hide unauthorized indices. This has been fixed by displaying the index names as they are resolved by the indices stats API. The outputs of these two APIs is now very similar: same index names, similar data but different format. Closes #37190
This changes the output of the `_cat/indices` API with `Security` enabled. It is possible to only display the index name (and possibly the index health, depending on the request options) but not its stats (doc count, merges, size, etc). This is the case for closed indices which have index metadata in the cluster state but no associated shards, hence no shard stats. However, when `Security` is enabled, and the request contains wildcards, **open** indices without stats are a common occurrence. This is because the index names in the response table are picked up directly from the cluster state which is not filtered by `Security`'s _indexNameExpressionResolver_, unlike the stats data which is populated by the indices stats API which does go through the index name resolver. This is a bug, because it is circumventing `Security`'s function to hide unauthorized indices. This has been fixed by displaying the index names as they are resolved by the indices stats API. The outputs of these two APIs is now very similar: same index names, similar data but different format. Closes #37190
@albertzaharovits The |
Elasticsearch version (
bin/elasticsearch --version
): 7.0.0-SNAPSHOTDescription of the problem including expected versus actual behavior:
When calling
_cat/indices
with no index list, indices for which the user does not have privileges simply omit the docs count and storage size information. However, calling the same API with an index for which the user does not have privileges (_cat/indices/index_you_cant_see_info_for
) returns a 403 error:I think the API should behave the same in either case, just return the data without storage size and docs count.
The text was updated successfully, but these errors were encountered: