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
Authorization failure when indexing document with new mappings to alias. #30597
Comments
Pinging @elastic/es-security |
This is in fact the case and was an intentional change introduced in #17048. A couple of thoughts come to mind, we can add the original indices to the request or we can handle this case specifically within our authorization code. We currently already have a special case for this, so I am leaning towards expanding that with a fix. |
This commit fixes an issue with dynamic mapping updates when an index operation is performed against an alias and when the user only has permissions to the alias. Dynamic mapping updates resolve the concrete index early to prevent issues so the information about the alias that the triggering operation was being executed against is lost. When security is enabled and a user only has privileges to the aias, this dynamic mapping update would be rejected as it is executing against the concrete index and not the alias. In order to handle this situation, the security code needs to look at the concrete index and the authorized indices of the user; if the concrete index is not authorized the code will attempt to find an alias that the user has permissions to update the mappings of. Closes elastic#30597
This commit fixes an issue with dynamic mapping updates when an index operation is performed against an alias and when the user only has permissions to the alias. Dynamic mapping updates resolve the concrete index early to prevent issues so the information about the alias that the triggering operation was being executed against is lost. When security is enabled and a user only has privileges to the alias, this dynamic mapping update would be rejected as it is executing against the concrete index and not the alias. In order to handle this situation, the security code needs to look at the concrete index and the authorized indices of the user; if the concrete index is not authorized the code will attempt to find an alias that the user has permissions to update the mappings of. Closes #30597
This commit fixes an issue with dynamic mapping updates when an index operation is performed against an alias and when the user only has permissions to the alias. Dynamic mapping updates resolve the concrete index early to prevent issues so the information about the alias that the triggering operation was being executed against is lost. When security is enabled and a user only has privileges to the alias, this dynamic mapping update would be rejected as it is executing against the concrete index and not the alias. In order to handle this situation, the security code needs to look at the concrete index and the authorized indices of the user; if the concrete index is not authorized the code will attempt to find an alias that the user has permissions to update the mappings of. Closes #30597
This commit fixes an issue with dynamic mapping updates when an index operation is performed against an alias and when the user only has permissions to the alias. Dynamic mapping updates resolve the concrete index early to prevent issues so the information about the alias that the triggering operation was being executed against is lost. When security is enabled and a user only has privileges to the alias, this dynamic mapping update would be rejected as it is executing against the concrete index and not the alias. In order to handle this situation, the security code needs to look at the concrete index and the authorized indices of the user; if the concrete index is not authorized the code will attempt to find an alias that the user has permissions to update the mappings of. Closes #30597
Elasticsearch version (
bin/elasticsearch --version
): 6.2.4Description of the problem including expected versus actual behavior:
If a user is allowed to write to an alias, but not its concrete index, then indexing a document with new mappings can produce the following authorization exception:
This behavior is confusing, because
write
permissions should allow for both indexing and updating mappings, and the user can successfully make a put mapping request directly.Note that if the user is also given
write
privileges to the underlying index, then attempting to index the document succeeds. This fact suggests that the implicitmappings
call during indexing is maybe being validated against the concrete index, instead of the alias.Related to #29874.
Steps to reproduce:
Gist: https://gist.github.com/jtibshirani/ff8ebcd235dc8be36ecd84543b29525d
The text was updated successfully, but these errors were encountered: