Update 3.0.4 to 3.0.x syntax surprises / bugs?
Hi, some things to note: 1) one of my client definitions has an opening parenthesis in its secret (no closing), which is not a problem for 3.0.4, but in current 3.0.x I get: /usr/local/freeradius/config/raddb/clients.conf[655]: Parse error after "sdfsre": unexpected token "(" Errors reading or parsing /usr/local/freeradius/config/raddb/radiusd.conf sdfsre are the characters of the secret preceding the ( . Should such a secret now be surrounded by quotes, or is that more like a bug? 2) When running, I see that SQL queries are getting executed correctly (I see the retrieved AVPs), but the section still bails out with Query Error (and the exact same config works fine in 3.0.4). Here's a sample: rlm_sql (sql-commonauth): Reserved connection (4) (35) sql-commonauth: EXPAND (SELECT id, username, attribute, value, op FROM %{control:RESTENA-SQL-Table} WHERE username='%{SQL-User-Name}') (35) sql-commonauth: --> (SELECT id, username, attribute, value, op FROM check_imap_ssha1 WHERE username='xxxcensoredxxx') rlm_sql (sql-commonauth): Executing query: '(SELECT id, username, attribute, value, op FROM check_imap_ssha1 WHERE username='xxxcensoredxxx')' (35) sql-commonauth: User found in radcheck table (35) sql-commonauth: Conditional check items matched, merging assignment check items (35) sql-commonauth: RESTENA-SSHA1-Password := 'XXXV4iX9qSO8BcMxDJ6P0FNINVALIDQ1MGo1ZmNuZXJoVzWXXX==' (35) sql-commonauth: ERROR: SQL query error rlm_sql (sql-commonauth): Released connection (4) (I changed username and retrieved hash in the mail) I couldn't continue testing 3.0.x with that situation, so I'm back to 3.0.4 for now. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
All shared secrets really should be in quotes , especially if they have interesting characters alan
Hi,
All shared secrets really should be in quotes , especially if they have interesting characters
Well, none of the examples in clients.conf has quotes. If the recommendation is to quote shared secrets by default, I'd suggest to update raddb/clients.conf to lead by good example :-) Stefan -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
Stefan Winter wrote:
Well, none of the examples in clients.conf has quotes.
In this case, flexibility can cause problems. The idea is that simple strings don't need quotes. But... that means that the parser gets excited over "special" characters. Putting the secret into quotes fixes that.
If the recommendation is to quote shared secrets by default, I'd suggest to update raddb/clients.conf to lead by good example :-)
I'll add some notes on when / where to use quoting. And double-check the parsing of unquoted "special" characters. Alan DeKok.
Stefan Winter wrote:
1) one of my client definitions has an opening parenthesis in its secret (no closing), which is not a problem for 3.0.4, but in current 3.0.x I get:
/usr/local/freeradius/config/raddb/clients.conf[655]: Parse error after "sdfsre": unexpected token "(" Errors reading or parsing /usr/local/freeradius/config/raddb/radiusd.conf
sdfsre are the characters of the secret preceding the ( .
Should such a secret now be surrounded by quotes, or is that more like a bug?
I've pushed a fix.
2) When running, I see that SQL queries are getting executed correctly (I see the retrieved AVPs), but the section still bails out with Query Error (and the exact same config works fine in 3.0.4). Here's a sample:
rlm_sql (sql-commonauth): Reserved connection (4) (35) sql-commonauth: EXPAND (SELECT id, username, attribute, value, op FROM %{control:RESTENA-SQL-Table} WHERE username='%{SQL-User-Name}') (35) sql-commonauth: --> (SELECT id, username, attribute, value, op FROM check_imap_ssha1 WHERE username='xxxcensoredxxx') rlm_sql (sql-commonauth): Executing query: '(SELECT id, username, attribute, value, op FROM check_imap_ssha1 WHERE username='xxxcensoredxxx')' (35) sql-commonauth: User found in radcheck table (35) sql-commonauth: Conditional check items matched, merging assignment check items (35) sql-commonauth: RESTENA-SSHA1-Password := 'XXXV4iX9qSO8BcMxDJ6P0FNINVALIDQ1MGo1ZmNuZXJoVzWXXX==' (35) sql-commonauth: ERROR: SQL query error rlm_sql (sql-commonauth): Released connection (4)
Hmm... it would be nice to know what that query error is. I've pushed some better error messages. Arran will also look into it. Alan DeKok.
participants (3)
-
Alan Buxey -
Alan DeKok -
Stefan Winter