Le 20-06-17 à 15 h 59, Alan DeKok a écrit :
On Jun 17, 2020, at 3:23 PM, Fabrice Durand <fdurand@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