Properly handle wildcards in data stream deletion requests #78463
Conversation
danhermann
added
>bug
v8.0.0
:Data Management/Data streams
| } | ||
| request.indices(names.toArray(Strings.EMPTY_ARRAY)); | ||
|
|
There was a problem hiding this comment.
I'm not sure that it's useful to duplicate the name resolution and system index validation logic in masterOperation and below in removeDataStream but the overwriting of the request's indices is the most narrow root cause of this bug.
There was a problem hiding this comment.
I think it's fine to double-check the validation so that we avoid the cluster state task if possible, so this seems reasonable to me.
|
Manually pinging @elastic/es-data-management (Team:Data Management) since GH's webhooks are 🤷 |
dakrone
left a comment
dakrone
left a comment
There was a problem hiding this comment.
LGTM, though could you please fill out the PR body with an explanation of what happened and how this fixes it for the sake of future Github searchability?
| } | ||
| request.indices(names.toArray(Strings.EMPTY_ARRAY)); | ||
|
|
There was a problem hiding this comment.
I think it's fine to double-check the validation so that we avoid the cluster state task if possible, so this seems reasonable to me.
|
Thanks, @dakrone. |
3 participants
The root cause of this bug was the replacement of the wildcard expression in the request's
indicesmember with the actual data streams that expression matched. In the case that the authz code had already replaced it with the*,-*token that means "no authorized data streams", the expression would be evaluated again, would match no data streams, and would set theindicesmember to an empty array. An empty array is equivalent to*, so all data streams would then be deleted.Fixes #78422