!= and !~ operators

[Joe Maimon]

Alan DeKok wrote:

> 
>   That makes sense.  It gets more difficult once multiple attributes
> of the same name are in a list.  I'll have to think about that some
> more.
> 

Codewise (well at least the patch I tried) its easier to deal with 
mutliple attributes if no attribute is also a successfull no match

>>
>>Perhaps a small poll to find out if anyone present relies on the current 
>>behavior of != ?
> 

Well I recall being bitten by != unexepcted behavior in the past and 
switching to !* (which also didnt work, which you took my 2 liner, which 
was also buggy, which the last patch includes a fix for)

Yep, its in my users file to deny certain users who dont have a 
Connect-Info == "value" attribute. So its unpatched behavior is actually 
NOT what I wanted/expected until I read man 5 users.

Perhaps the direction to be taken here is to add another way to negate 
the == test that behaves like the patches != ?

>   Sure.  Since it's not really documented, I'm not sure what the
> existing systems *expect*.
> 
man 5 users states that

Attribute != Value
             As a check item, matches if the given attribute is in the 
request, AND does not have the given value.
             Not allowed as a reply item.


> 
>   The use there is probably better done by something like:
> 
>   ...
>     reply -= { 
> 	  foo == bar,
> 	  ...
>     }
> 
>   i.e. "remove from reply attributes that match these conditions".
> The behavior of '==' and '=~' is always the same, which helps.

That syntax never occurred to me. It would be nice if it worked, so I 
tested it.

/etc/freeradius/policy.txt[8]: Unexpected token -=

But policy is not complete, hence this portion of discussion.

> 
> 
>   I would prefer to fix the policy module so it's complete and stable.
> With a little bit of effort, it can solve many of the same problems
> that the existing modules do, in a more general manner.
> 
> 

The policy module is a very powerfull concept, allowing one to use 
pseduo code to manipulate the attribute lists. I assume you mean it can 
make redundant modules like attr_filter attr_rewrite and others as well.


>   Yeah, that's bad.  But the main reason is that paircompare() has
> it's problems.  It's meant to support the "users" file, and extending
> it for any other purpose is a bad idea.
> 

paircompare() supports xlat, supports registered comparison functions, 
and seems to be the code equivalent to man 5 users which is the 
freeradius authoritative source as to how operators are to be used.

I havent checked but I would hope that rlm_sql and friends also used it 
as well, since their goal is to reproduce the users file environment in 
a db friendly environment.

If you mean paircompare() should be used whenever one want users file 
like handling of comparisons, I would tend to agree.

> 
>>Not like my opinion actually matters much.
> 
> 
>   <shrug> See the number of bufs fixes that have gonr in recently
> based on your comments.

Drop in the bucket compared to what the you and the existing 
contributors have done.

> 
>   Alan DeKok.
> - 
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
> 
>