Skip to content
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

Closed
bmcconaghy opened this issue Jan 7, 2019 · 7 comments · Fixed by #38824
Closed

403 for no index permission from _cat/indices call #37190

bmcconaghy opened this issue Jan 7, 2019 · 7 comments · Fixed by #38824
Assignees
Labels
:Data Management/CAT APIs Text APIs behind /_cat :Security/Authorization Roles, Privileges, DLS/FLS, RBAC/ABAC

Comments

@bmcconaghy
Copy link

Elasticsearch version (bin/elasticsearch --version): 7.0.0-SNAPSHOT

Description 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:

{
  "error": {
    "root_cause": [
      {
        "type": "security_exception",
        "reason": "action [indices:monitor/stats] is unauthorized for user [billy]"
      }
    ],
    "type": "security_exception",
    "reason": "action [indices:monitor/stats] is unauthorized for user [billy]"
  },
  "status": 403
}

I think the API should behave the same in either case, just return the data without storage size and docs count.

@javanna
Copy link
Member

javanna commented Jan 8, 2019

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 javanna added the :Security/Authorization Roles, Privileges, DLS/FLS, RBAC/ABAC label Jan 8, 2019
@bmcconaghy
Copy link
Author

@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.

@javanna
Copy link
Member

javanna commented Jan 8, 2019

@bmcconaghy I see what you mean, I agree with you.

@jakelandis jakelandis added the :Data Management/CAT APIs Text APIs behind /_cat label Jan 15, 2019
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-core-features

@albertzaharovits
Copy link
Contributor

@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.

I agree as well. I think the prob is in RestIndicesAction

Table tab = buildTable(request, concreteIndices, clusterHealthResponse,
. I have an idea of a simple fix for this, but _cat APIs probably need some cleansing overall.

@albertzaharovits albertzaharovits self-assigned this Jan 28, 2019
@bmcconaghy
Copy link
Author

Thanks for taking a look at this @albertzaharovits !

albertzaharovits added a commit that referenced this issue Feb 14, 2019
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 added a commit that referenced this issue Feb 14, 2019
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
@rhass
Copy link

rhass commented Aug 16, 2019

@albertzaharovits The _cat/shards call seems to be affected by this same issue. Is this intentional for the shards API?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Data Management/CAT APIs Text APIs behind /_cat :Security/Authorization Roles, Privileges, DLS/FLS, RBAC/ABAC
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants