Relax the index access control check for scroll searches #61446
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
albertzaharovits
added
>bug
:Security/Authorization
|
Pinging @elastic/es-security (:Security/Authorization) |
albertzaharovits
added a commit
that referenced
this pull request
Aug 27, 2020
The check introduced by #60640 for scroll searches, in which we log if the index access control before the query and fetch phases differs from when the scroll context is created, is too strict, leading to spurious warning log messages. The check verifies instance equality but this assumes that the fetch phase is executed in the same thread context as the scroll context validation. However, this is not true if the scroll search is executed cross-cluster, and even for local scroll searches it is an unfounded assumption. The check is hence reduced to a null check for the index access. The fact that the access control is suitable given the indices that are actually accessed (by the scroll) will be done in a follow-up, after we better regulate the creation of index access controls in general.
albertzaharovits
added a commit
that referenced
this pull request
Aug 27, 2020
The check introduced by #60640 for scroll searches, in which we log if the index access control before the query and fetch phases differs from when the scroll context is created, is too strict, leading to spurious warning log messages. The check verifies instance equality but this assumes that the fetch phase is executed in the same thread context as the scroll context validation. However, this is not true if the scroll search is executed cross-cluster, and even for local scroll searches it is an unfounded assumption. The check is hence reduced to a null check for the index access. The fact that the access control is suitable given the indices that are actually accessed (by the scroll) will be done in a follow-up, after we better regulate the creation of index access controls in general.
albertzaharovits
added a commit
that referenced
this pull request
Aug 27, 2020
The check introduced by #60640 for scroll searches, in which we log if the index access control before the query and fetch phases differs from when the scroll context is created, is too strict, leading to spurious warning log messages. The check verifies instance equality but this assumes that the fetch phase is executed in the same thread context as the scroll context validation. However, this is not true if the scroll search is executed cross-cluster, and even for local scroll searches it is an unfounded assumption. The check is hence reduced to a null check for the index access. The fact that the access control is suitable given the indices that are actually accessed (by the scroll) will be done in a follow-up, after we better regulate the creation of index access controls in general.
albertzaharovits
added a commit
that referenced
this pull request
Aug 27, 2020
)" This reverts commit 9a42f3f.
albertzaharovits
added a commit
to albertzaharovits/elasticsearch
that referenced
this pull request
Aug 27, 2020
The check introduced by elastic#60640 for scroll searches, in which we log if the index access control before the query and fetch phases differs from when the scroll context is created, is too strict, leading to spurious warning log messages. The check verifies instance equality but this assumes that the fetch phase is executed in the same thread context as the scroll context validation. However, this is not true if the scroll search is executed cross-cluster, and even for local scroll searches it is an unfounded assumption. The check is hence reduced to a null check for the index access. The fact that the access control is suitable given the indices that are actually accessed (by the scroll) will be done in a follow-up, after we better regulate the creation of index access controls in general.
albertzaharovits
added a commit
that referenced
this pull request
Aug 27, 2020
The check introduced by #60640 for scroll searches, in which we log if the index access control before the query and fetch phases differs from when the scroll context is created, is too strict, leading to spurious warning log messages. The check verifies instance equality but this assumes that the fetch phase is executed in the same thread context as the scroll context validation. However, this is not true if the scroll search is executed cross-cluster, and even for local scroll searches it is an unfounded assumption. The check is hence reduced to a null check for the index access. The fact that the access control is suitable given the indices that are actually accessed (by the scroll) will be done in a follow-up, after we better regulate the creation of index access controls in general.
jimczi
added a commit
to jimczi/elasticsearch
that referenced
this pull request
Sep 2, 2020
This change makes sure that we validate the reader context (`SearchOperationListener#validateReaderContext) before any other operation. Relates elastic#61446
jimczi
added a commit
that referenced
this pull request
Sep 7, 2020
This change makes sure that reader context is validated (`SearchOperationListener#validateReaderContext) before any other operation and that it is correctly recycled or removed at the end of the operation. This commit also fixes a race condition bug that would allocate the security reader for scrolls more than once. Relates #61446 Co-authored-by: Nhat Nguyen <[email protected]>
dnhatn
added a commit
to dnhatn/elasticsearch
that referenced
this pull request
Sep 10, 2020
) This change makes sure that reader context is validated (`SearchOperationListener#validateReaderContext) before any other operation and that it is correctly recycled or removed at the end of the operation. This commit also fixes a race condition bug that would allocate the security reader for scrolls more than once. Relates elastic#61446 Co-authored-by: Nhat Nguyen <[email protected]>
dnhatn
added a commit
that referenced
this pull request
Sep 10, 2020
This change makes sure that reader context is validated (`SearchOperationListener#validateReaderContext) before any other operation and that it is correctly recycled or removed at the end of the operation. This commit also fixes a race condition bug that would allocate the security reader for scrolls more than once. Relates #61446 Co-authored-by: Nhat Nguyen <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The check introduced by #60640 for scroll searches, in which we log if the index access control before the query and fetch phases differs from when the scroll context is created, is too strict, leading to spurious warning log messages.
The check verifies instance equality but this assumes that the fetch phase is executed in the same thread context as the scroll context validation. However, this is not true if the scroll search is executed cross-cluster, and even for local scroll searches it is an unfounded assumption.
The check is hence reduced to a
nullcheck for the index access. The fact that the access control is suitable given the indices that are actually accessed (by the scroll) will be done in a follow-up, after we better regulate the creation of index access controls in general.