Remove security-policy from config_ChainParse()
but NOT from var_OptionParse(). Rationale: At a shallow level, this breaks the command line use badly. At a deeper level: We still do security enforcement in var_OptionParse(). In practice, the config chain strings are always coming from (part of) the value of string configuration variable, which is parsed by var_OptionParse(). Hence, as long as these variables are all tagged as "unsafe", only trusted input can ever reach config_ChainParse(). There are other (intractable?) issues with checking configuration chain strings: First, we would also need to check the module name in front of the {var1=val1,...} stuff. Second, some modules parse their configuration chain manually, i.e. they don't call config_ChainParse() and sometimes do not register their variables as configuration items (e.g. the sout duplicate module). If you have a super-duper idea on how to improve this, you're welcome, but in the mean time... Signed-off-by: Rémi Denis-Courmont <rem@videolan.org> Vaguely-acked-by: Pierre d'Herbemont <pdherbemont@free.fr>
Showing
Please register or sign in to comment