safe_characters issue

[Durand fabrice]

Le 20-06-17 à 15 h 59, Alan DeKok a écrit :
> On Jun 17, 2020, at 3:23 PM, Fabrice Durand <fdurand at inverse.ca> wrote:
>> sorry to bother you.
>    Fixing bugs is what I do...
>
>> I did one last test and built new binary and revert few commits in 3.0.21 (attached to this email) in the rlm_sql modules and now freeradius take the safe_characters values from sql_degraded{...} section and not the sql {...} section anymore. (like it worked in freeradius 3.0.13)
>>
>> My skills in C are not good enough to find the issue but it looks that the "sql_escape_func" use the main sql section.
>    The sql_escape_func() uses whatever configuration is in the SQL connection that it's using.
>
>    i.e. If you configure sql_degraded to use the connection pool from the main SQL module, then the escaping is done using that configuration.
>
>   So you have:
> sql sql_degraded {
> ...
>          pool = sql
> }
>
>    Which means that the "safe_characters" is taken from the main "sql" module.
>
>    I admit that this behaviour is somewhat surprising, but.. I also have to ask, why use different "safe_characters" for connections to the same back-end database?  Do the safe_characters really change, depending on the SQL module, and not the database?

Oh ok it make sense now, i was disturbed to see in the debug that 
"safe_characters" was set to the values i needed in the sql_degraded 
section and it let me though that my config was ok.

Btw i did it wrong since the behavior was different with 3.0.13 and it 
let me though that it was a regression.

If it's the way it works i am ok with that.

>
>    My $0.02 is to just set "auto_escape = yes", and the problem goes away.  All escaping is done via the database library (not FreeRADIUS), and everything Just Works.

I will make a new try but the first test with that didn't worked.

Thanks for your support.

Regards

Fabrice

>    Alan DeKok.
>
>
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html