Fix an authorization error when LogsPatternUsageService attempts to update logsdb.prior_logs_usage cluster setting
#128050
Conversation
This file contains hidden or 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
…gs_usage` cluster setting. The following failure occurs when the LogsPatternUsageService updates the `logsb.prior_logs_usage` cluster setting: ``` [2025-05-13T17:11:21,685][DEBUG ][o.e.x.l.LogsPatternUsageService] [test-cluster-0] Failed to update [logsdb.prior_logs_usage] org.elasticsearch.ElasticsearchSecurityException: action [cluster:admin/settings/update] is unauthorized for user [_system] with effective roles [_system], this action is granted by the cluster privileges [manage,all] at org.elasticsearch.xcore@8.19.0-SNAPSHOT/org.elasticsearch.xpack.core.security.support.Exceptions.authorizationError(Exceptions.java:36) at org.elasticsearch.security@8.19.0-SNAPSHOT/org.elasticsearch.xpack.security.authz.AuthorizationService.denialException(AuthorizationService.java:1014) at org.elasticsearch.security@8.19.0-SNAPSHOT/org.elasticsearch.xpack.security.authz.AuthorizationService.actionDenied(AuthorizationService.java:991) at org.elasticsearch.security@8.19.0-SNAPSHOT/org.elasticsearch.xpack.security.authz.AuthorizationService.actionDenied(AuthorizationService.java:980) at org.elasticsearch.security@8.19.0-SNAPSHOT/org.elasticsearch.xpack.security.authz.AuthorizationService.actionDenied(AuthorizationService.java:970) at org.elasticsearch.security@8.19.0-SNAPSHOT/org.elasticsearch.xpack.security.authz.AuthorizationService.authorizeSystemUser(AuthorizationService.java:706) at org.elasticsearch.security@8.19.0-SNAPSHOT/org.elasticsearch.xpack.security.authz.AuthorizationService.authorize(AuthorizationService.java:320) at org.elasticsearch.security@8.19.0-SNAPSHOT/org.elasticsearch.xpack.security.action.filter.SecurityActionFilter.lambda$applyInternal$5(SecurityActionFilter.java:178) ``` This results in the `logsdb.prior_logs_usage` cluster setting not being set and causes the LogsPatternUsageService to continuously attempt to update the mentioned setting every 1 minute. The result of this is that the mentioned setting is never set, which if a cluster upgrades to 9.x, causes logsdb to be enabled by default. Which shouldn't happen for clusters upgrading from 8.x with data streams in the `logs-*-*` namespace. Unfortunately, this bug wasn't noticed given that the error wasn't visible (only if DEBUG logging was enabled) and the tests that test this functionality specifically don't run with security enabled. The fix is to use OriginSettingClient client instead of node client directly, so that xpack internal user is used, which does have to privileges to update cluster settings.
|
Pinging @elastic/es-storage-engine (Team:StorageEngine) |
|
Hi @martijnvg, I've created a changelog YAML for you. |
jfreden
approved these changes
May 14, 2025
|
How problematic is this issue? Should we postpone the update to 8.18.1 (from 8.17.5)? |
This issue shouldn't affect upgrading to any 8.x version. Starting from 8.18.0, ES sets the |
|
Thanks for the review @jfreden! |
martijnvg
added
the
auto-backport
martijnvg
changed the title
logsdb.prior_logs_usage cluster settinglogsdb.prior_logs_usage cluster setting
💚 Backport successful
|
martijnvg
added a commit
to martijnvg/elasticsearch
that referenced
this pull request
May 14, 2025
…pdate `logsdb.prior_logs_usage` cluster setting (elastic#128050) The following failure occurs when the LogsPatternUsageService updates the `logsb.prior_logs_usage` cluster setting: ``` [2025-05-13T17:11:21,685][DEBUG ][o.e.x.l.LogsPatternUsageService] [test-cluster-0] Failed to update [logsdb.prior_logs_usage] org.elasticsearch.ElasticsearchSecurityException: action [cluster:admin/settings/update] is unauthorized for user [_system] with effective roles [_system], this action is granted by the cluster privileges [manage,all] at org.elasticsearch.xcore@8.19.0-SNAPSHOT/org.elasticsearch.xpack.core.security.support.Exceptions.authorizationError(Exceptions.java:36) at org.elasticsearch.security@8.19.0-SNAPSHOT/org.elasticsearch.xpack.security.authz.AuthorizationService.denialException(AuthorizationService.java:1014) at org.elasticsearch.security@8.19.0-SNAPSHOT/org.elasticsearch.xpack.security.authz.AuthorizationService.actionDenied(AuthorizationService.java:991) at org.elasticsearch.security@8.19.0-SNAPSHOT/org.elasticsearch.xpack.security.authz.AuthorizationService.actionDenied(AuthorizationService.java:980) at org.elasticsearch.security@8.19.0-SNAPSHOT/org.elasticsearch.xpack.security.authz.AuthorizationService.actionDenied(AuthorizationService.java:970) at org.elasticsearch.security@8.19.0-SNAPSHOT/org.elasticsearch.xpack.security.authz.AuthorizationService.authorizeSystemUser(AuthorizationService.java:706) at org.elasticsearch.security@8.19.0-SNAPSHOT/org.elasticsearch.xpack.security.authz.AuthorizationService.authorize(AuthorizationService.java:320) at org.elasticsearch.security@8.19.0-SNAPSHOT/org.elasticsearch.xpack.security.action.filter.SecurityActionFilter.lambda$applyInternal$5(SecurityActionFilter.java:178) ``` This results in the `logsdb.prior_logs_usage` cluster setting not being set and causes the LogsPatternUsageService to continuously attempt to update the mentioned setting every 1 minute. The result of this is that the mentioned setting is never set, which if a cluster upgrades to 9.x, causes logsdb to be enabled by default. Which shouldn't happen for clusters upgrading from 8.x with data streams in the `logs-*-*` namespace. Unfortunately, this bug wasn't noticed given that the error wasn't visible (only if DEBUG logging was enabled) and the tests that test this functionality specifically don't run with security enabled. The fix is to use OriginSettingClient client instead of node client directly, so that xpack internal user is used, which does have to privileges to update cluster settings.
elasticsearchmachine
pushed a commit
that referenced
this pull request
May 14, 2025
…pdate `logsdb.prior_logs_usage` cluster setting (#128050) (#128076) The following failure occurs when the LogsPatternUsageService updates the `logsb.prior_logs_usage` cluster setting: ``` [2025-05-13T17:11:21,685][DEBUG ][o.e.x.l.LogsPatternUsageService] [test-cluster-0] Failed to update [logsdb.prior_logs_usage] org.elasticsearch.ElasticsearchSecurityException: action [cluster:admin/settings/update] is unauthorized for user [_system] with effective roles [_system], this action is granted by the cluster privileges [manage,all] at org.elasticsearch.xcore@8.19.0-SNAPSHOT/org.elasticsearch.xpack.core.security.support.Exceptions.authorizationError(Exceptions.java:36) at org.elasticsearch.security@8.19.0-SNAPSHOT/org.elasticsearch.xpack.security.authz.AuthorizationService.denialException(AuthorizationService.java:1014) at org.elasticsearch.security@8.19.0-SNAPSHOT/org.elasticsearch.xpack.security.authz.AuthorizationService.actionDenied(AuthorizationService.java:991) at org.elasticsearch.security@8.19.0-SNAPSHOT/org.elasticsearch.xpack.security.authz.AuthorizationService.actionDenied(AuthorizationService.java:980) at org.elasticsearch.security@8.19.0-SNAPSHOT/org.elasticsearch.xpack.security.authz.AuthorizationService.actionDenied(AuthorizationService.java:970) at org.elasticsearch.security@8.19.0-SNAPSHOT/org.elasticsearch.xpack.security.authz.AuthorizationService.authorizeSystemUser(AuthorizationService.java:706) at org.elasticsearch.security@8.19.0-SNAPSHOT/org.elasticsearch.xpack.security.authz.AuthorizationService.authorize(AuthorizationService.java:320) at org.elasticsearch.security@8.19.0-SNAPSHOT/org.elasticsearch.xpack.security.action.filter.SecurityActionFilter.lambda$applyInternal$5(SecurityActionFilter.java:178) ``` This results in the `logsdb.prior_logs_usage` cluster setting not being set and causes the LogsPatternUsageService to continuously attempt to update the mentioned setting every 1 minute. The result of this is that the mentioned setting is never set, which if a cluster upgrades to 9.x, causes logsdb to be enabled by default. Which shouldn't happen for clusters upgrading from 8.x with data streams in the `logs-*-*` namespace. Unfortunately, this bug wasn't noticed given that the error wasn't visible (only if DEBUG logging was enabled) and the tests that test this functionality specifically don't run with security enabled. The fix is to use OriginSettingClient client instead of node client directly, so that xpack internal user is used, which does have to privileges to update cluster settings.
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 following failure occurs when the LogsPatternUsageService updates the
logsb.prior_logs_usagecluster setting:This results in the
logsdb.prior_logs_usagecluster setting not being set and causes the LogsPatternUsageService to continuously attempt to update the mentioned setting every 1 minute. The result of this is that the mentioned setting is never set, which if a cluster upgrades to 9.x, causes logsdb to be enabled by default. Which shouldn't happen for clusters upgrading from 8.x with data streams in thelogs-*-*namespace.Unfortunately, this bug wasn't noticed given that the error wasn't visible (only if DEBUG logging was enabled) and the tests that test this functionality specifically don't run with security enabled.
The fix is to use OriginSettingClient client instead of node client directly, so that xpack internal user is used, which does have to privileges to update cluster settings.