Version 3.0.4 sql groups handling issue

Philippe MARASSE philippe.marasse at ch-poitiers.fr
Fri Nov 28 18:23:22 CET 2014


Le 28/11/2014 16:51, Arran Cudbard-Bell a écrit :
>> On 28 Nov 2014, at 10:26, Philippe MARASSE <philippe.marasse at 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 at 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

-------------- next part --------------
--- rlm_sql.c-orig	2014-11-28 14:09:47.738796013 +0100
+++ rlm_sql.c	2014-11-28 18:05:11.630574073 +0100
@@ -685,11 +685,26 @@
 		goto finish;
 	}
 
+	/*
+	 * Does not examine groups if any group query is missing from config
+	 */
+	if (! (inst->config->authorize_group_check_query && *inst->config->authorize_group_check_query &&
+		   inst->config->authorize_group_reply_query && *inst->config->authorize_group_reply_query) ) {
+
+		/*
+		 *	If there's no reply query configured, then we assume
+		 *	FALL_THROUGH_NO, which is the same as the users file if you
+		 *	had no reply attributes.
+		 */
+		*do_fall_through = FALL_THROUGH_DEFAULT;
+
+		goto finish;
+	}
+
 	entry = head;
 	do {
 		pairstrcpy(sql_group, entry->name);
 
-		if (inst->config->authorize_group_check_query && *inst->config->authorize_group_check_query) {
 			vp_cursor_t cursor;
 			VALUE_PAIR *vp;
 
@@ -718,11 +733,14 @@
 			if ((rows > 0) &&
 			    (paircompare(request, request->packet->vps, check_tmp, &request->reply->vps) != 0)) {
 				pairfree(&check_tmp);
-				entry = entry->next;
 
+			// If it does not match... continue to next group
 				continue;
 			}
 
+		/*
+		 * At this point, this group matches
+		 */
 			RDEBUG2("Group \"%s\": Conditional check items matched", entry->name);
 			rcode = RLM_MODULE_OK;
 
@@ -738,9 +756,7 @@
 			REXDENT();
 			radius_pairmove(request, &request->config_items, check_tmp, true);
 			check_tmp = NULL;
-		}
 
-		if (inst->config->authorize_group_reply_query && *inst->config->authorize_group_reply_query) {
 			/*
 			 *	Now get the reply pairs since the paircompare matched
 			 */
@@ -767,17 +783,15 @@
 
 			radius_pairmove(request, &request->reply->vps, reply_tmp, true);
 			reply_tmp = NULL;
+
 		/*
-		 *	If there's no reply query configured, then we assume
-		 *	FALL_THROUGH_NO, which is the same as the users file if you
-		 *	had no reply attributes.
+		 * Now examine fall-through... not enabled => bail out
 		 */
-		} else {
-			*do_fall_through = FALL_THROUGH_DEFAULT;
+		if (*do_fall_through != FALL_THROUGH_YES) {
+			break;
 		}
 
-		entry = entry->next;
-	} while (entry != NULL && (*do_fall_through == FALL_THROUGH_YES));
+	} while ((entry = entry->next) != NULL);
 
 finish:
 	talloc_free(head);
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4326 bytes
Desc: Signature cryptographique S/MIME
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20141128/6bb2e202/attachment-0001.bin>


More information about the Freeradius-Users mailing list