Bogus default attrs file?

[Tomas Hoger]

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.