Skip to content
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

Fixed READ_ACTIONS required by TermsAggregationEvaluator #4582

Merged
merged 2 commits into from
Jul 29, 2024

Conversation

nibix
Copy link
Collaborator

@nibix nibix commented Jul 19, 2024

The READ_ACTIONS array is passed by TermsAggregationEvaluator to securityRoles.getAllPermittedIndicesForDashboards() which checks whether privileges are available for all actions specified in READ_ACTIONS. READ_ACTIONS also contained the string "indices:data/read/field_caps*", which is actually wrong, because it is not an action but looks like pattern. However, the code behind securityRoles.getAllPermittedIndicesForDashboards() will never treat these strings as patterns. The "*" is only considered a normal, bare character. Patterns (via WildcardMatcher class) will be only applied to these strings.

This had the effect that a bare privilege "indices:data/read/field_caps" was not sufficient to fulfill the requirement. It was necessary to have either "indices:data/read/field_caps*" in ones roles.yml or something broader like "indices:data/read/*". The latter is the most likely case, which is the reason why in most cases this gets unnoticed.

Observed while working on #3870 and decoupled from #4380.

Description

[Describe what this change achieves]

  • Category: Bug fix
  • Why these changes are required? - The code created an impression that patterns were supported at the particular place, while they were actually not supported. For the changes introduced in Optimized Privilege Evaluation #4380, this also caused a performance penalty, as the specified string was not an actual action and needed to be specially treated.
  • What is the old behavior before changes and new behavior after changes? - No significant changes. It will be sufficient to specify the privilege "indices:data/read/field_caps" instead of ""indices:data/read/field_caps*" to have field caps on indices properly working, but in practice this seems to be a rare case.

Issues Resolved

Contributes to #3870

Testing

Integration testing via existing tests

Check List

  • Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

The READ_ACTIONS array is passed by TermsAggregationEvaluator to securityRoles.getAllPermittedIndicesForDashboards() which checks whether privileges are available for all actions specified in READ_ACTIONS. READ_ACTIONS also contained the string "indices:data/read/field_caps*", which is actually wrong, because it is not an action but looks like pattern. However, the code behind securityRoles.getAllPermittedIndicesForDashboards() will never treat these strings as patterns. The "*" is only considered a normal, bare character. Patterns (via WildcardMatcher class) will be only applied to these strings.

This had the effect that a bare privilege "indices:data/read/field_caps" was not sufficient to fulfill the requirement. It was necessary to have either "indices:data/read/field_caps*" in ones roles.yml or something broader like "indices:data/read/*". The latter is the most likely case, which is the reason why in most cases this gets unnoticed.

Signed-off-by: Nils Bandener <[email protected]>
Copy link
Member

@DarshitChanpura DarshitChanpura left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @nibix for addressing this! is there a way this can be tested to ensure that * is a bare character here and would not expand?

@nibix
Copy link
Collaborator Author

nibix commented Jul 22, 2024

@DarshitChanpura

Thanks @nibix for addressing this! is there a way this can be tested to ensure that * is a bare character here and would not expand?

This is quite easy to verify by a simple manual static code analysis. This is the call path:

final Set<String> allPermittedIndices = securityRoles.getAllPermittedIndicesForDashboards(
resolved,
user,
READ_ACTIONS,
resolver,
clusterService
);

retVal.addAll(sr.getAllResolvedPermittedIndices(Resolved._LOCAL_ALL, user, actions, resolver, cs, Function.identity()));

final boolean patternMatch = matcherModification.apply(p.getPerms()).matchAll(actions);

This shows that the actions parameter is never passed to a WildcardMatcher.create() method. However, it is only this method which gives you the possibility to interpret strings with patterns.

@cwperks
Copy link
Member

cwperks commented Jul 23, 2024

@nibix wdyt about removing all hardcoding and pulling the static action name from core if possible (it may not be possible in all cases)?

Related issue: #4515

@nibix
Copy link
Collaborator Author

nibix commented Jul 23, 2024

wdyt about removing all hardcoding and pulling the static action name from core if possible (it may not be possible in all cases)?

sure

Copy link

codecov bot commented Jul 23, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 65.25%. Comparing base (26a4c0b) to head (57bd4f3).
Report is 5 commits behind head on main.

Additional details and impacted files

Impacted file tree graph

@@            Coverage Diff             @@
##             main    #4582      +/-   ##
==========================================
- Coverage   65.28%   65.25%   -0.04%     
==========================================
  Files         317      317              
  Lines       22272    22272              
  Branches     3582     3582              
==========================================
- Hits        14541    14534       -7     
- Misses       5939     5946       +7     
  Partials     1792     1792              
Files Coverage Δ
...security/privileges/TermsAggregationEvaluator.java 57.14% <ø> (ø)

... and 1 file with indirect coverage changes

@nibix
Copy link
Collaborator Author

nibix commented Jul 26, 2024

@cwperks @DarshitChanpura is there anything still missing that blocks this?

@cwperks
Copy link
Member

cwperks commented Jul 26, 2024

@cwperks @DarshitChanpura is there anything still missing that blocks this?

It needs one more approval. @DarshitChanpura @peternied @scrawfor99 @willyborankin @reta @RyanL1997 Can one of you take a look?

@cwperks cwperks added the backport 2.x backport to 2.x branch label Jul 29, 2024
@cwperks cwperks merged commit c5ebb99 into opensearch-project:main Jul 29, 2024
42 of 43 checks passed
opensearch-trigger-bot bot pushed a commit that referenced this pull request Jul 29, 2024
Signed-off-by: Nils Bandener <[email protected]>
(cherry picked from commit c5ebb99)
Signed-off-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport 2.x backport to 2.x branch
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants