Hello, I'm upgrading from FR 3.0.0 to 3.0.4, during the tests, I've ran into an issue : - My NAS are sorted into 2 different huntgroups - My users are members of 2 SQL groups - Each SQL group is attached to one huntgroup Under v3.0.4 group processing stops when the first group get processed whether huntgroup matches or not. I think I've found the culprit line 621 in rlm_sql.c, the continue instruction skips lines 659 & 660 : pairdelete(&request->packet->vps, PW_SQL_GROUP, 0, TAG_ANY); entry = entry->next; As far as Fall-Through's default value has changed from 1 in v3.0.0 to FALL_THROUGH_DEFAULT (0), my second group never get processed. Another test : I've added Fall-Through = Yes into my radreply table : bang, infinite loop on the first group ! From my log : rlm_sql (sql): Executing query: 'SELECT id, groupname, attribute, Value, op FROM radgroupcheck WHERE groupname = 'pcs-sites' ORDER BY id' (1) sql : EXPAND SELECT id, groupname, attribute, Value, op FROM radgroupcheck WHERE groupname = '%{Sql-Group}' ORDER BY id (1) sql : --> SELECT id, groupname, attribute, Value, op FROM radgroupcheck WHERE groupname = 'pcs-sites' ORDER BY id rlm_sql (sql): Executing query: 'SELECT id, groupname, attribute, Value, op FROM radgroupcheck WHERE groupname = 'pcs-sites' ORDER BY id' (1) sql : EXPAND SELECT id, groupname, attribute, Value, op FROM radgroupcheck WHERE groupname = '%{Sql-Group}' ORDER BY id (1) sql : --> SELECT id, groupname, attribute, Value, op FROM radgroupcheck WHERE groupname = 'pcs-sites' ORDER BY id rlm_sql (sql): Executing query: 'SELECT id, groupname, attribute, Value, op FROM radgroupcheck WHERE groupname = 'pcs-sites' ORDER BY id' (1) sql : EXPAND SELECT id, groupname, attribute, Value, op FROM radgroupcheck WHERE groupname = '%{Sql-Group}' ORDER BY id (1) sql : --> SELECT id, groupname, attribute, Value, op FROM radgroupcheck WHERE groupname = 'pcs-sites' ORDER BY id rlm_sql (sql): Executing query: 'SELECT id, groupname, attribute, Value, op FROM radgroupcheck WHERE groupname = 'pcs-sites' ORDER BY id' (1) sql : EXPAND SELECT id, groupname, attribute, Value, op FROM radgroupcheck WHERE groupname = '%{Sql-Group}' ORDER BY id (1) sql : --> SELECT id, groupname, attribute, Value, op FROM radgroupcheck WHERE groupname = 'pcs-sites' ORDER BY id rlm_sql (sql): Executing query: 'SELECT id, groupname, attribute, Value, op FROM radgroupcheck WHERE groupname = 'pcs-sites' ORDER BY id' (1) sql : EXPAND SELECT id, groupname, attribute, Value, op FROM radgroupcheck WHERE groupname = '%{Sql-Group}' ORDER BY id (1) sql : --> SELECT id, groupname, attribute, Value, op FROM radgroupcheck WHERE groupname = 'pcs-sites' ORDER BY id I can post the entire log if needed. BTW, I've got a look on github, branch 3.0.x, rlm_sql.c seems to have the same issue (continue on line 720, skipped lines 769 & 770). Regards. -- Philippe MARASSE Responsable pôle Infrastructures - DSIO Centre Hospitalier Henri Laborit CS 10587 - 370 avenue Jacques Coeur 86021 Poitiers Cedex Tel : 05.49.44.57.19
On 27 Nov 2014, at 12:08, Philippe MARASSE <philippe.marasse@ch-poitiers.fr> wrote:
Hello,
I'm upgrading from FR 3.0.0 to 3.0.4, during the tests, I've ran into an issue :
- My NAS are sorted into 2 different huntgroups - My users are members of 2 SQL groups - Each SQL group is attached to one huntgroup
Under v3.0.4 group processing stops when the first group get processed whether huntgroup matches or not.
I think I've found the culprit line 621 in rlm_sql.c, the continue instruction skips lines 659 & 660 : pairdelete(&request->packet->vps, PW_SQL_GROUP, 0, TAG_ANY); entry = entry->next;
As far as Fall-Through's default value has changed from 1 in v3.0.0 to FALL_THROUGH_DEFAULT (0), my second group never get processed.
Another test : I've added Fall-Through = Yes into my radreply table : bang, infinite loop on the first group ! From my log :
Oops, that's not meant to happen. Your diagnosis is correct, that was the issue. I've fixed the code, and made it a little more efficient. There's no reason to add/remove SQL-Group on every iteration, we just need to add it once and change its value. Also spotted a minor issue where if you'd set Fall-Through in the user's reply items, and had no reply query for groups, it would have automatically gone on to query for profiles. Could you check the code in v3.0.x to make sure the infinite loop issue is fixed for you? -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On 27 Nov 2014, at 13:24, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On 27 Nov 2014, at 12:08, Philippe MARASSE <philippe.marasse@ch-poitiers.fr> wrote:
Hello,
I'm upgrading from FR 3.0.0 to 3.0.4, during the tests, I've ran into an issue :
- My NAS are sorted into 2 different huntgroups - My users are members of 2 SQL groups - Each SQL group is attached to one huntgroup
Under v3.0.4 group processing stops when the first group get processed whether huntgroup matches or not.
That's the correct behaviour. That was a long standing bug in rlm_sql which was corrected. In the users file if all the check items match for an entry, you stop processing, and don't evaluate other entries. The same should be true for rlm_sql. You should need to explicitly add Fall-Through = yes to process additional groups. The last group processed also controls whether profiles are processed, which is slightly weird, but as the ordering of the group assignments is controlled by the administrator, it allows maximum flexibility. If you really want tight control over profile processing you could add a couple of dummy groups for Fall-Through = yes and Fall-Through = no, and list them at the end of user's group lists. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On 27 Nov 2014, at 13:36, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On 27 Nov 2014, at 13:24, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On 27 Nov 2014, at 12:08, Philippe MARASSE <philippe.marasse@ch-poitiers.fr> wrote:
Hello,
I'm upgrading from FR 3.0.0 to 3.0.4, during the tests, I've ran into an issue :
- My NAS are sorted into 2 different huntgroups - My users are members of 2 SQL groups - Each SQL group is attached to one huntgroup
Under v3.0.4 group processing stops when the first group get processed whether huntgroup matches or not.
That's the correct behaviour. That was a long standing bug in rlm_sql which was corrected.
Sorry, misread. That bug was to do with something else. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Le 27/11/2014 20:13, Arran Cudbard-Bell a écrit :
On 27 Nov 2014, at 13:36, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On 27 Nov 2014, at 13:24, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On 27 Nov 2014, at 12:08, Philippe MARASSE <philippe.marasse@ch-poitiers.fr> wrote:
Hello,
I'm upgrading from FR 3.0.0 to 3.0.4, during the tests, I've ran into an issue :
- My NAS are sorted into 2 different huntgroups - My users are members of 2 SQL groups - Each SQL group is attached to one huntgroup
Under v3.0.4 group processing stops when the first group get processed whether huntgroup matches or not. That's the correct behaviour. That was a long standing bug in rlm_sql which was corrected. Thanks for your patch. I'll test that this afternoon.
So I'm wondering about the expected behavior : actually sql group processing stops after the first group, although the check item does not match (in my case Huntgroup does not match). Is this expected ? In my mind, the group processing stops after the first match of a group, which would be fine in my case. Regards. -- Philippe MARASSE Responsable pôle Infrastructures - DSIO Centre Hospitalier Henri Laborit CS 10587 - 370 avenue Jacques Coeur 86021 Poitiers Cedex Tel : 05.49.44.57.19
On Nov 28, 2014, at 3:06 AM, Philippe MARASSE <philippe.marasse@ch-poitiers.fr> wrote:
So I'm wondering about the expected behavior : actually sql group processing stops after the first group, although the check item does not match (in my case Huntgroup does not match). Is this expected ?
No. It should match and stop, or not match and continue. Alan DeKok.
Le 28/11/2014 14:41, Alan DeKok a écrit :
On Nov 28, 2014, at 3:06 AM, Philippe MARASSE <philippe.marasse@ch-poitiers.fr> wrote:
So I'm wondering about the expected behavior : actually sql group processing stops after the first group, although the check item does not match (in my case Huntgroup does not match). Is this expected ? No. It should match and stop, or not match and continue. Perfect ! So I've not misunderstood :-).
I've just tested the patch proposed by Arran. Unfortunately, this time it does not continue after trying to get user check attributes : (0) sql: EXPAND %{User-Name} (0) sql: --> 90fba6e49245 (0) sql: SQL-User-Name set to '90fba6e49245' rlm_sql (sql): Reserved connection (4) (0) sql: EXPAND SELECT id, username, attribute, value, op FROM radcheck WHERE username = '%{SQL-User-Name}' ORDER BY id (0) sql: --> SELECT id, username, attribute, value, op FROM radcheck WHERE username = '90fba6e49245' ORDER BY id rlm_sql (sql): Executing query: 'SELECT id, username, attribute, value, op FROM radcheck WHERE username = '90fba6e49245' ORDER BY id' ERROR: (0) sql: SQL query error getting check attributes rlm_sql (sql): Released connection (4) (0) [sql] = fail (0) } # authorize = fail (0) Using Post-Auth-Type Reject Although SQL query returns : mysql> SELECT id, username, attribute, value, op FROM radcheck WHERE username = '90fba6e49245' ORDER BY id; +-----+--------------+--------------------+--------------+----+ | id | username | attribute | value | op | +-----+--------------+--------------------+--------------+----+ | 426 | 90fba6e49245 | Cleartext-Password | 90fba6e49245 | := | +-----+--------------+--------------------+--------------+----+ 1 row in set (0.00 sec) This time I don't understand why ?? Regards. -- Philippe MARASSE Responsable pôle Infrastructures - DSIO Centre Hospitalier Henri Laborit CS 10587 - 370 avenue Jacques Coeur 86021 Poitiers Cedex Tel : 05.49.44.57.19
On 28 Nov 2014, at 10:26, Philippe MARASSE <philippe.marasse@ch-poitiers.fr> wrote:
Le 28/11/2014 14:41, Alan DeKok a écrit :
On Nov 28, 2014, at 3:06 AM, Philippe MARASSE <philippe.marasse@ch-poitiers.fr> wrote:
So I'm wondering about the expected behavior : actually sql group processing stops after the first group, although the check item does not match (in my case Huntgroup does not match). Is this expected ? No. It should match and stop, or not match and continue. Perfect ! So I've not misunderstood :-).
I've just tested the patch proposed by
Unrelated issue, should be fixed now. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Le 28/11/2014 16:51, Arran Cudbard-Bell a écrit :
On 28 Nov 2014, at 10:26, Philippe MARASSE <philippe.marasse@ch-poitiers.fr> wrote:
Le 28/11/2014 14:41, Alan DeKok a écrit :
On Nov 28, 2014, at 3:06 AM, Philippe MARASSE <philippe.marasse@ch-poitiers.fr> wrote:
So I'm wondering about the expected behavior : actually sql group processing stops after the first group, although the check item does not match (in my case Huntgroup does not match). Is this expected ? No. It should match and stop, or not match and continue. Perfect ! So I've not misunderstood :-).
I've just tested the patch proposed by Unrelated issue, should be fixed now. Just downloaded, it half works : as long as I have Fall-Through = yes on this user, it works :
(0) sql: EXPAND %{User-Name} (0) sql: --> 90fba6e49245 (0) sql: SQL-User-Name set to '90fba6e49245' rlm_sql (sql): Reserved connection (4) (0) sql: EXPAND SELECT id, username, attribute, value, op FROM radcheck WHERE username = '%{SQL-User-Name}' ORDER BY id (0) sql: --> SELECT id, username, attribute, value, op FROM radcheck WHERE username = '90fba6e49245' ORDER BY id rlm_sql (sql): Executing query: 'SELECT id, username, attribute, value, op FROM radcheck WHERE username = '90fba6e49245' ORDER BY id' (0) sql: User found in radcheck table (0) sql: Conditional check items matched, merging assignment check items (0) sql: Cleartext-Password := '90fba6e49245' (0) sql: EXPAND SELECT id, username, attribute, value, op FROM radreply WHERE username = '%{SQL-User-Name}' ORDER BY id (0) sql: --> SELECT id, username, attribute, value, op FROM radreply WHERE username = '90fba6e49245' ORDER BY id rlm_sql (sql): Executing query: 'SELECT id, username, attribute, value, op FROM radreply WHERE username = '90fba6e49245' ORDER BY id' (0) sql: User found in radreply table, merging reply items (0) sql: Fall-Through = Yes (0) sql: EXPAND SELECT groupname FROM radusergroup WHERE username = '%{SQL-User-Name}' ORDER BY priority (0) sql: --> SELECT groupname FROM radusergroup WHERE username = '90fba6e49245' ORDER BY priority rlm_sql (sql): Executing query: 'SELECT groupname FROM radusergroup WHERE username = '90fba6e49245' ORDER BY priority' (0) sql: User found in the group table (0) sql: EXPAND SELECT id, groupname, attribute, Value, op FROM radgroupcheck WHERE groupname = '%{Sql-Group}' ORDER BY id (0) sql: --> SELECT id, groupname, attribute, Value, op FROM radgroupcheck WHERE groupname = 'pcs-sites' ORDER BY id rlm_sql (sql): Executing query: 'SELECT id, groupname, attribute, Value, op FROM radgroupcheck WHERE groupname = 'pcs-sites' ORDER BY id' (0) sql: EXPAND SELECT id, groupname, attribute, Value, op FROM radgroupcheck WHERE groupname = '%{Sql-Group}' ORDER BY id (0) sql: --> SELECT id, groupname, attribute, Value, op FROM radgroupcheck WHERE groupname = 'pcs-miletrie' ORDER BY id rlm_sql (sql): Executing query: 'SELECT id, groupname, attribute, Value, op FROM radgroupcheck WHERE groupname = 'pcs-miletrie' ORDER BY id' (0) sql: Group "pcs-miletrie": Conditional check items matched (0) sql: Group "pcs-miletrie": Merging assignment check items (0) sql: EXPAND SELECT id, groupname, attribute, value, op FROM radgroupreply WHERE groupname = '%{Sql-Group}' ORDER BY id (0) sql: --> SELECT id, groupname, attribute, value, op FROM radgroupreply WHERE groupname = 'pcs-miletrie' ORDER BY id rlm_sql (sql): Executing query: 'SELECT id, groupname, attribute, value, op FROM radgroupreply WHERE groupname = 'pcs-miletrie' ORDER BY id' (0) sql: Group "pcs-miletrie": Merging reply items (0) sql: Tunnel-Type := VLAN (0) sql: Tunnel-Medium-Type := IEEE-802 (0) sql: Tunnel-Private-Group-Id := '100' rlm_sql (sql): Released connection (4) (0) [sql] = ok As mentioned, the first group does not match according to its Hunt-Group, the next group matches and reply items are correctly sent. If I remove Fall-Through = Yes from radreply table : (1) sql: EXPAND %{User-Name} (1) sql: --> 90fba6e49245 (1) sql: SQL-User-Name set to '90fba6e49245' rlm_sql (sql): Reserved connection (6) (1) sql: EXPAND SELECT id, username, attribute, value, op FROM radcheck WHERE username = '%{SQL-User-Name}' ORDER BY id (1) sql: --> SELECT id, username, attribute, value, op FROM radcheck WHERE username = '90fba6e49245' ORDER BY id rlm_sql (sql): Executing query: 'SELECT id, username, attribute, value, op FROM radcheck WHERE username = '90fba6e49245' ORDER BY id' (1) sql: User found in radcheck table (1) sql: Conditional check items matched, merging assignment check items (1) sql: Cleartext-Password := '90fba6e49245' (1) sql: EXPAND SELECT id, username, attribute, value, op FROM radreply WHERE username = '%{SQL-User-Name}' ORDER BY id (1) sql: --> SELECT id, username, attribute, value, op FROM radreply WHERE username = '90fba6e49245' ORDER BY id rlm_sql (sql): Executing query: 'SELECT id, username, attribute, value, op FROM radreply WHERE username = '90fba6e49245' ORDER BY id' (1) sql: EXPAND SELECT groupname FROM radusergroup WHERE username = '%{SQL-User-Name}' ORDER BY priority (1) sql: --> SELECT groupname FROM radusergroup WHERE username = '90fba6e49245' ORDER BY priority rlm_sql (sql): Executing query: 'SELECT groupname FROM radusergroup WHERE username = '90fba6e49245' ORDER BY priority' (1) sql: User found in the group table (1) sql: EXPAND SELECT id, groupname, attribute, Value, op FROM radgroupcheck WHERE groupname = '%{Sql-Group}' ORDER BY id (1) sql: --> SELECT id, groupname, attribute, Value, op FROM radgroupcheck WHERE groupname = 'pcs-sites' ORDER BY id rlm_sql (sql): Executing query: 'SELECT id, groupname, attribute, Value, op FROM radgroupcheck WHERE groupname = 'pcs-sites' ORDER BY id' rlm_sql (sql): Released connection (6) (1) [sql] = ok The second group, which would match, is not processed. According to Alan's answer, it should have been processed. IMHO line 780 (rlm_sql.c) is involved : } while (entry != NULL && (*do_fall_through == FALL_THROUGH_YES)); If Fall-Through is not enabled, the next groups are never processed. So I've modified the logic in rlm_sql.c (see attachment), my first tests seems good. I'll try more tests next monday. Thanks. Regards. -- Philippe MARASSE Responsable pôle Infrastructures - DSIO Centre Hospitalier Henri Laborit CS 10587 - 370 avenue Jacques Coeur 86021 Poitiers Cedex Tel : 05.49.44.57.19
On 28 Nov 2014, at 12:23, Philippe MARASSE <philippe.marasse@ch-poitiers.fr> wrote:
Le 28/11/2014 16:51, Arran Cudbard-Bell a écrit :
On 28 Nov 2014, at 10:26, Philippe MARASSE <philippe.marasse@ch-poitiers.fr> wrote:
Le 28/11/2014 14:41, Alan DeKok a écrit :
On Nov 28, 2014, at 3:06 AM, Philippe MARASSE <philippe.marasse@ch-poitiers.fr> wrote:
So I'm wondering about the expected behavior : actually sql group processing stops after the first group, although the check item does not match (in my case Huntgroup does not match). Is this expected ? No. It should match and stop, or not match and continue. Perfect ! So I've not misunderstood :-).
I've just tested the patch proposed by Unrelated issue, should be fixed now. Just downloaded, it half works : as long as I have Fall-Through = yes on this user, it works :
Hmm, no that patch is a little off. Fixed the issue (and tested locally). -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
participants (3)
-
Alan DeKok -
Arran Cudbard-Bell -
Philippe MARASSE