Bogus default attrs file?
Tomas Hoger
thoger at pobox.sk
Thu Jan 11 00:33:01 CET 2007
Hi Alan!
Thanks for reply.
On Wed, Jan 10, 2007 at 09:32:37AM -0500, Alan DeKok wrote:
> Could you check the code in the CVS head? It was updated
> significantly, to clarify some of these issues. I think it may work a
> little better.
I have not tried latest CVS code yet, but I have read it. It seems to have
same issue. That's why I also included patch for CVS version in my
previous email, but I guess it has been overlooked ;). Here is slightly
improved version:
--- rlm_attr_filter.c 2006-11-22 22:44:19.000000000 +0100
+++ rlm_attr_filter.c.new 2007-01-10 23:52:21.000000000 +0100
@@ -68,7 +68,11 @@
compare = paircmp(check_item, reply_item);
if (compare == 1) {
++*(pass);
- } else {
+ } else if (check_item->operator != T_OP_CMP_EQ
+#ifdef HAVE_REGEX_H
+ && check_item->operator != T_OP_REG_EQ
+#endif
+ ) {
++*(fail);
}
--- 8< ---
Code still runs every check_item - reply_item combination through
check_pair function, which uses paircmp to do the hard work, but always
increments pass or fail counter. After checking filter rules:
attribute == value1,
attribute == value2
Value of fail will always be >0 and attribute will be dropped.
However, I think it would be nice to have way to enumerate list of
permitted values (without having to write regex). That's why I suggested
possible change of semantics of == and =~ operators in attr filter rules.
Single failed comparison will not drop attribute and any matching value
will suffice.
Are there any other changes in CVS version of rlm_attr_filter I have
overlooked which can make it behave as described in attrs file?
th.
More information about the Freeradius-Users
mailing list