Reconsider default behavior for DNFOF in 3.0.0 #5195
Labels
untriaged
Require the attention of the repository maintainers and may need to be prioritized
Comments
github-actions
bot
added
the
untriaged
|
Answering your question from opensearch-project/OpenSearch#17650 (comment) here: I do believe that when using Dashboards one should have DNFOF enabled, yes. Still, DNFOF has design flaws. Thus, I am not sure if having it enabled always makes sense. Actually, I wrote down an RFC on DNFOF a while ago: |
5 tasks
This would be a good change. I think this would be a good improvement to the system that reduces the level of complexity in grokking how security works in opensearch. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Coming from conversation on opensearch-project/OpenSearch#17650
When a user is mapped to a role that has full access to a subset of indices in a cluster then by default
_cat/indiceswill fail with a Forbidden error instead of returning the indices that are visible to the user. As a workaround, we instruct cluster administrators to consider toggling do_not_fail_on_forbidden to true.With this issue, I propose changing the default behavior (at least for
_cat/indices) to always return the indices visible to the user regardless if a cluster has DNFOF set to true.I believe this is possible by updating this line to return true if the action is
indices:monitor/settings/getWhat do the maintainers think of this change in default behavior for 3.0.0 release?
The text was updated successfully, but these errors were encountered: