[bug]: config.c: Template inheritance is incorrect for ast_variable_retrieve #244
Closed
1 task done
Assignees
Labels
Comments
InterLinked1
added a commit
to InterLinked1/asterisk
that referenced
this issue
Aug 9, 2023
ast_variable_retrieve currently returns the first match for a variable, as opposed to the last one. This is problematic because modules that load config settings by explicitly calling ast_variable_retrieve on a variable name (as opposed to iterating through all the directives as specified) will end up taking the first specified value, such as the default value from the template rather than the actual effective value in an individual config section, leading to the wrong config. This fixes this by making ast_variable_retrieve return the last match, or the most recently overridden one, as the effective setting. This is similar to what the -1 index in the AST_CONFIG function does. There is another function, ast_variable_find_last_in_list, that does something similar. However, it's a slightly different API, and it sees virtually no usage in Asterisk. ast_variable_retrieve is what most things use so this is currently the relevant point of breakage. In practice, this is unlikely to cause any breakage, since there would be no logical reason to use an inherited value rather than an explicitly overridden value when loading a config. ASTERISK-30370 #close Resolves: asterisk#244 UpgradeNote: Config variables retrieved explicitly by name now return the most recently overriding value as opposed to the base value (e.g. from a template). This is equivalent to retrieving a config setting using the -1 index to the AST_CONFIG function. The major implication of this is that modules processing configs by explicitly retrieving variables by name will now get the effective value of a variable as overridden in a config rather than the first-set value (from a template), which is consistent with how other modules load config settings.
jcolp
added
support-level-core
1 task
InterLinked1
added a commit
to InterLinked1/asterisk
that referenced
this issue
Oct 23, 2024
ast_variable_update currently sets the first match for a variable, as opposed to the last one. This issue is complementary to that raised in asterisk#244. This is incorrect and results in the wrong (or no) action being taken in cases where a section inherits from a template section. When the traversal occurs to update the setting, the existing code erroneously would use the first of possibly multiple matches in its update logic, which is wrong. Now, explicitly use the last match in the traversal, which will ensure that the actual setting is updated properly, and not skipped or ignored because a template from which the setting's section inherits was used for comparison. Resolves: asterisk#960 UpgradeNote: Config variables, when set/updated, such as via AMI, will now have the corresponding setting updated, even if their sections inherit from template sections.
asterisk-org-access-app bot
pushed a commit
that referenced
this issue
Nov 12, 2024
ast_variable_update currently sets the first match for a variable, as opposed to the last one. This issue is complementary to that raised in #244. This is incorrect and results in the wrong (or no) action being taken in cases where a section inherits from a template section. When the traversal occurs to update the setting, the existing code erroneously would use the first of possibly multiple matches in its update logic, which is wrong. Now, explicitly use the last match in the traversal, which will ensure that the actual setting is updated properly, and not skipped or ignored because a template from which the setting's section inherits was used for comparison. Resolves: #960 UpgradeNote: Config variables, when set/updated, such as via AMI, will now have the corresponding setting updated, even if their sections inherit from template sections.
InterLinked1
added a commit
to InterLinked1/asterisk
that referenced
this issue
Dec 3, 2024
ast_variable_retrieve currently returns the first match for a variable, as opposed to the last one. This is problematic because modules that load config settings by explicitly calling ast_variable_retrieve on a variable name (as opposed to iterating through all the directives as specified) will end up taking the first specified value, such as the default value from the template rather than the actual effective value in an individual config section, leading to the wrong config. This fixes this by making ast_variable_retrieve return the last match, or the most recently overridden one, as the effective setting. This is similar to what the -1 index in the AST_CONFIG function does. There is another function, ast_variable_find_last_in_list, that does something similar. However, it's a slightly different API, and it sees virtually no usage in Asterisk. ast_variable_retrieve is what most things use so this is currently the relevant point of breakage. In practice, this is unlikely to cause any breakage, since there would be no logical reason to use an inherited value rather than an explicitly overridden value when loading a config. ASTERISK-30370 #close Resolves: asterisk#244 UpgradeNote: Config variables retrieved explicitly by name now return the most recently overriding value as opposed to the base value (e.g. from a template). This is equivalent to retrieving a config setting using the -1 index to the AST_CONFIG function. The major implication of this is that modules processing configs by explicitly retrieving variables by name will now get the effective value of a variable as overridden in a config rather than the first-set value (from a template), which is consistent with how other modules load config settings.
asterisk-org-access-app bot
pushed a commit
that referenced
this issue
Dec 10, 2024
ast_variable_retrieve currently returns the first match for a variable, as opposed to the last one. This is problematic because modules that load config settings by explicitly calling ast_variable_retrieve on a variable name (as opposed to iterating through all the directives as specified) will end up taking the first specified value, such as the default value from the template rather than the actual effective value in an individual config section, leading to the wrong config. This fixes this by making ast_variable_retrieve return the last match, or the most recently overridden one, as the effective setting. This is similar to what the -1 index in the AST_CONFIG function does. There is another function, ast_variable_find_last_in_list, that does something similar. However, it's a slightly different API, and it sees virtually no usage in Asterisk. ast_variable_retrieve is what most things use so this is currently the relevant point of breakage. In practice, this is unlikely to cause any breakage, since there would be no logical reason to use an inherited value rather than an explicitly overridden value when loading a config. ASTERISK-30370 #close Resolves: #244 UpgradeNote: Config variables retrieved explicitly by name now return the most recently overriding value as opposed to the base value (e.g. from a template). This is equivalent to retrieving a config setting using the -1 index to the AST_CONFIG function. The major implication of this is that modules processing configs by explicitly retrieving variables by name will now get the effective value of a variable as overridden in a config rather than the first-set value (from a template), which is consistent with how other modules load config settings.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Severity
Major
Versions
20.0.1 (really all versions, ever)
Components/Modules
config.c
Operating Environment
N/A
Frequency of Occurrence
Constant
Issue Description
Imported from JIRA: https://issues.asterisk.org/jira/browse/ASTERISK-30370
If values are specified in a template and then overridden, behavior is currently wrong when explicitly retrieving a variable, as reading a config line by line will result in the overriden value being used (correct), but explicitly asking for it will return the earliest set value, which is that provided by the template.
As a result, modules can pick up the wrong values when loading config items in this manner, and users can get very confused.
This fixes this by adjusting ast_variable_retrieve to return the last match instead of the first (the equivalent of -1 to the AST_CONFIG function), so that the most recently specified/overridden value is returned and behavior is consistent.
Relevant log output
No response
Asterisk Issue Guidelines
The text was updated successfully, but these errors were encountered: