-
Notifications
You must be signed in to change notification settings - Fork 24.8k
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
x-pack security plugin concurrency issue #81901
Comments
This issue by the way, may find the answer of a question marked as todo in the PR #25728. Wildcard resolver throw exceptions regarding non wildcarded expressions because SecurityActionFilter rewrite the wildcard to the concreteIndices. @javanna @martijnvg |
Pinging @elastic/es-data-management (Team:Data Management) |
I think this is the same problem that was investigated from #45652 (comment) onwards in that issue. #47159 was opened as a result of that, but never worked on. It's great that this issue provides and up-to-date way to recreate the problem, as the old way I found to reproduce it is over 2 years old now and might not work any more. |
So is there any plan to fix it ? I would like to do some job ,if needed. @droberts195 |
Thanks @mushao999 for sharing this bug and the reproduction. After reading and understanding this reproduction, the fact that the wildcard expression is expanded/resolved on the coordinating node (the node that first accepts a request), but actual usage of the resolved indices from the wildcard expression happens on the elected master node can cause error like this one. Essentially the request contains stale information, in this case resolved indices (which were valid on the coordinating node at time the request was accepted), and one of these indices no longer exists when request is being handled on the elected master node (due to the addition and removal of Today due to historical reasons, index expression resolution happens in two places. In the security ( I don't know whether there is a quick fix for this bug. Maybe the get alias api (and other indices based APIs) could instead of always throwing a |
Elasticsearch version (
bin/elasticsearch --version
):6.3.3, 6.8.0, 7.7.0, 7.10.0, 7.16.1 , 8.1.0(build from latest master branch)
Plugins installed: []
with x-apack security enabled, no more plugins
JVM version (
java -version
):follow the mini runtime java version of each version
OS version (
uname -a
if on a Unix-like system):Linux node2 3.10.0-327.ali2019.alios7.x86_64 #1 SMP Sun Jan 19 18:21:42 CST 2020 x86_64 x86_64 x86_64 GNU/Linux
Description of the problem including expected versus actual behavior:
Cluster has an index named
index1
and an alias namedalias1
which points toindex1
. We may have some chance to get aIndexNotFoundException
of an irrelvantindex2
when we callGetAlias API
foralias1
if we are creatingindex2
at the same time.Steps to reproduce:
Please include a minimal but complete recreation of the problem,
including (e.g.) index creation, mappings, settings, query etc. The easier
you make for us to reproduce it, the more likely that somebody will take the
time to look at it.
script 1(create index1, alias1. Then clean and create index2 looply. You can choose not to clean old index, thing will not changed , we just want to keep cluster clean)
script2(get alias1 continuously)
Provide logs (if relevant):
the stack trace of 8.1.0 list as follow:
Most likey cause:
we have analyzed and debuged the code and get the following conclusion:
TransportGetAliasAction
of master node, where they get cluster state to validate index's existence.(java/org/elasticsearch/cluster/metadata/IndexNameExpressionResolver.java:1227)indices
param in the request will be rewritten to a list of all indices from the ClusterState in theSecurityActionFilter
ofcoordinate node
.(org/elasticsearch/xpack/security/authz/IndicesAndAliasesResolver.java:257)two phase cluster state plublication
can make corrdinate nodes' cluster state newer than the master node.Need help
Please help reivew our issue and analysis, and give us some suggestion how to fix it.
The text was updated successfully, but these errors were encountered: