group sensitive per user return attributes with rlm_sql
I'm trying to work out (in 2.0.0) how to achieve "matching group specific per user reply attributes" using rlm_sql, based on which group(s) matched the authentication request. So, for instance, a user might belong to both DIALUP and WIRELESS groups. But I only want the per-user reply attributes relevant to the access request being processed, for instance Mikrotik-Rate-Limit only gets set if the request matched WIRELESS (via a huntgroup match). As far as I can tell, this would require some surgery to rlm_sql, and an additional (optional) CheckGroup column in the 'radreply' table: UserName,Attribute,op,Value,CheckGroup radiustest,Mikrotik-Rate-Limit,=,512k/512k,WIRELESS radiustest,Some-Dialup-Attribute,=,foo,DIALUP radiustest,Some-Common-Attribute,=,bar, So the authorize_reply_query could then be something like: authorize_reply_query = "\ SELECT id, UserName, Attribute, Value, op \ FROM ${authreply_table} \ WHERE Username = '%{SQL-User-Name}' \ AND (CheckGroup = '' OR CheckGroup IN(%{control:Matched-Groups})) ORDER BY id" Then if the request came from a NAS which has a matching check attribute for the WIRELESS group, only 'radreply' items with CheckGroup of WIRELESS (and those with no CheckGroup) would be returned. So in this case, Mikrotik-Rate-Limit and Some-Common-Attribute. Obviously the surgery to rlm_sql would be in building %{control:Matched-Groups}, which would mean shuffling some code around, as currently the groups aren't looked at till after the per-user reply attributes are processed. Or is there some other way of doing this I'm spacing on? -- hugh
[I just noticed I forgot to set Plain Text on my original post. Re-posting in plain text. Mea Maxima Culpa, won't happen again] I'm trying to work out (in 2.0.0) how to achieve "matching group specific per user reply attributes" using rlm_sql, based on which group(s) matched the authentication request. So, for instance, a user might belong to both DIALUP and WIRELESS groups. But I only want the per-user reply attributes relevant to the access request being processed, for instance Mikrotik-Rate-Limit only gets set if the request matched WIRELESS (via a huntgroup match). As far as I can tell, this would require some surgery to rlm_sql, and an additional (optional) CheckGroup column in the 'radreply' table: UserName,Attribute,op,Value,CheckGroup radiustest,Mikrotik-Rate-Limit,=,512k/512k,WIRELESS radiustest,Some-Dialup-Attribute,=,foo,DIALUP radiustest,Some-Common-Attribute,=,bar, So the authorize_reply_query could then be something like: authorize_reply_query = "\ SELECT id, UserName, Attribute, Value, op \ FROM ${authreply_table} \ WHERE Username = '%{SQL-User-Name}' \ AND (CheckGroup = '' OR CheckGroup IN(%{control:Matched-Groups})) ORDER BY id" Then if the request came from a NAS which has a matching check attribute for the WIRELESS group, only 'radreply' items with CheckGroup of WIRELESS (and those with no CheckGroup) would be returned. So in this case, Mikrotik-Rate-Limit and Some-Common-Attribute. Obviously the surgery to rlm_sql would be in building %{control:Matched-Groups}, which would mean shuffling some code around, as currently the groups aren't looked at till after the per-user reply attributes are processed. Or is there some other way of doing this I'm spacing on? -- hugh
Dumb question time. Short version: Can someone pretty please remind me how to do in C what would amount to this in perl ... my($checked_groups); while (...)) { ... $checked_groups .= $group_list_tmp->groupname . ","; } chop $checked_groups; &pairmake("control:Matched-Groups", $checked_groups, T_OP_EQ); My apologies for such a basic C question. I've been deeply corrupted by Perl and PHP, to the point that 'malloc' is a dim and distant memory. Long version:
I'm trying to work out (in 2.0.0) how to achieve "matching group specific per user reply attributes" using rlm_sql, based on which group(s) matched the authentication request.
As per my post just now on the -users list, I found a really simple approach that works for Huntgroup. However, I'm still ditzing around with a patch to rlm_sql.c that does what I originally fantasized about, whereby 'radreply' attributes optionally only match if associated with a (new) matching CheckGroup column in 'radreply'. This would do what I'm currently achieving with my Huntgroup hack, but in a more generic fashion, and without having to maintain a Huntgroup config. As per my original description:
As far as I can tell, this would require some surgery to rlm_sql, and an additional (optional) CheckGroup column in the 'radreply' table:
UserName,Attribute,op,Value,CheckGroup radiustest,Mikrotik-Rate-Limit,=,512k/512k,WIRELESS radiustest,Some-Dialup-Attribute,=,foo,DIALUP radiustest,Some-Common-Attribute,=,bar,
I've almost got this working, by simply adding a 'rlm_sql_pre_process_groups' function, optionally called before the radcheck/radreply processing in rlm_sql_authorize. The 'pre_process' function goes thru the groups, finds the ones with matching checks, and builds a comma separated string of the matching Groupnames, which gets assigned to %{control:Matched-Groups}. I then use that in the authorize_reply_query as:
AND (CheckGroup = '' OR CheckGroup IN(%{control:Matched-Groups}))
So far so good. And it's all working ... except that I haven't used C in about 15 years, basically since the day I discovered Perl. And I've totally forgotten all about C's dynamic memory allocation. And no matter what combination of char *, char[x], malloc, strcpy and strcat I use, I'm ending up with garbage at the start of the string I'm trying to build.
-- hugh
-- hugh
On Wed 04 Jul 2007, Hugh Messenger wrote:
Dumb question time.
Short version:
Can someone pretty please remind me how to do in C what would amount to this in perl ...
so do it in perl with rlm_perl :-) -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
so do it in perl with rlm_perl :-)
I did think about that. Trouble is, that means doubling up on the all the group related queries. First in the perl pre-process step, then in the normal rlm_sql group processing. By doing this as a patch to rlm_sql itself, I can cache the results of the pre_process, and splice those into the original rlm_sql_process_groups function, instead of running all the queries again. May seem far fetched, given that I can't remember how to strcat properly! But a lot of my old C chops are still there, it's just this darn string concat that's giving me problems! I'll see if I can dig up my (very!) old Kernighan and Ritchie.
Peter Nixon
-- hugh
participants (2)
-
Hugh Messenger -
Peter Nixon