- Package:
- dbconfig-common
- Source:
- dbconfig-common
- Submitter:
- Francois Gouget
- Date:
- 2015-08-14 19:51:04 UTC
- Severity:
- normal
Dear Maintainer, While installing the cacti package I got asked for a password for the cacti database. I had the misfortune of typing a password containing a double-quote. This resulted in cacti not starting due to an obvious syntax error in '/etc/cacti/debian.php': $database_password = "prickly"cacti"; Escaping the double-quote at least got the Cacti website to come up. I did not test further with that password however.
clone 710331 -1 reassign -1 dbconfig-common retitle -1 special characters should be escaped when used in templates block 710331 by -1 retitle 710331 cacti: no special character handling in configuration thanks Cacti uses dbconfig-common to configure the cacti database connection. However, as far as I can tell dbconfig-common doesn't do anything to ensure proper handling of special characters in strings. If I have a password for my database containing special characters, I get them all as they were, making the procedure impossible to use with templates. E.g. the following line ends up exactly like it is: x" '\ making either " or ' as string delimiters (or no delimiters) in php or sh not doing the right thing. Of course the proper escaping depends on the language of the template, e.g. for sh the above line could be escaped as: 'x" '\''\' or with a lot more care to take all variations into account: "x\" '\\" for php, it needs to be something like 'x" \'\\' or "x\" '\\" and probably for other languages even something different. Of course, the template in cacti should not contain the quotes anymore when dbconfig-common escapes the strings properly. So I clone the bug accordingly.
Hi all,
The logic to dbconfig-generate-include in the dbconfig-common source is
slightly flawed [1] in the sense that it escapes all variable depending
on the language in case the dbconfig-common templates are used, but
forgets to do this language specific when a package template is used. As
I don't think there is a watertight check possible to determine what
language the variables should be escaped for (and e.g. in case of php/sh
it also depends on how the strings are quoted (' vs ")) I propose to
extend the format from "template" to "template | phptemplate |
shtemplate | perltemplate | cpptemplate" and use the right escape
algorithm depending on the selected format. I propose to keep "template"
as-is but let it generate a warning.
Objections? Other ideas or solutions?
Paul
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=716841