Re: Bogus default attrs file?

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.

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html