You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ranger.apache.org by "Vyom Mani Tiwari (Jira)" <ji...@apache.org> on 2026/08/12 11:05:00 UTC
[jira] [Updated] (RANGER-5742) Inconsistent handling of service config fields by name vs. declared type
[ https://issues.apache.org/jira/browse/RANGER-5742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Vyom Mani Tiwari updated RANGER-5742:
-------------------------------------
Description:
Service configuration read/write logic decides how a config value is displayed and stored by comparing its key against a single hardcoded field name, instead of consulting that field's declared type in the service definition. Service definitions can mark other fields with the same type under different names, and those fields don't get the same handling as the hardcoded one.
*Details*
* Affects: {{security-admin}} ({{{}RangerServiceService{}}}, {{{}ServiceDBStore{}}})
* Both the read path (service config retrieval) and the write path (service config storage) compare a config key against one fixed string rather than looking up the field's declared type from the service definition.
* Result: behavior is inconsistent across service types — fields with the same declared type are handled differently purely because of their name.
* Confirmed for two service definitions, where two fields per definition share the same declared type as the hardcoded field but use different names.
was:
ervice configuration read/write logic decides how a config value is displayed and stored by comparing its key against a single hardcoded field name, instead of consulting that field's declared type in the service definition. Service definitions can mark other fields with the same type under different names, and those fields don't get the same handling as the hardcoded one.
*Details*
* Affects: {{security-admin}} ({{{}RangerServiceService{}}}, {{{}ServiceDBStore{}}})
* Both the read path (service config retrieval) and the write path (service config storage) compare a config key against one fixed string rather than looking up the field's declared type from the service definition.
* Result: behavior is inconsistent across service types — fields with the same declared type are handled differently purely because of their name.
* Confirmed for two service definitions, where two fields per definition share the same declared type as the hardcoded field but use different names.
> Inconsistent handling of service config fields by name vs. declared type
> ------------------------------------------------------------------------
>
> Key: RANGER-5742
> URL: https://issues.apache.org/jira/browse/RANGER-5742
> Project: Ranger
> Issue Type: Bug
> Components: admin
> Affects Versions: 2.8.0, 2.9.0
> Reporter: Vyom Mani Tiwari
> Assignee: Vyom Mani Tiwari
> Priority: Critical
> Fix For: 3.0.0
>
>
> Service configuration read/write logic decides how a config value is displayed and stored by comparing its key against a single hardcoded field name, instead of consulting that field's declared type in the service definition. Service definitions can mark other fields with the same type under different names, and those fields don't get the same handling as the hardcoded one.
> *Details*
> * Affects: {{security-admin}} ({{{}RangerServiceService{}}}, {{{}ServiceDBStore{}}})
> * Both the read path (service config retrieval) and the write path (service config storage) compare a config key against one fixed string rather than looking up the field's declared type from the service definition.
> * Result: behavior is inconsistent across service types — fields with the same declared type are handled differently purely because of their name.
> * Confirmed for two service definitions, where two fields per definition share the same declared type as the hardcoded field but use different names.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)