Multivalued attributes

Arran Cudbard-Bell a.cudbardb at freeradius.org
Thu Jul 31 18:27:40 CEST 2014


On 31 Jul 2014, at 04:33, Alan DeKok <aland at deployingradius.com> wrote:

> Herwin Weststrate wrote:
>> That would make the following two expressions different:
>> 
>>  if (Attr[*] !~ /regex/)
>>  if (!(Attr[*] =~ /regex/))
> 
>  In general, != and !~ should be the same as !(.. == ) and !(.. =~)

I don't think that's correct in this case.

!= is equivalent to attrA ⊄ attrB
== is equivalent to attrA ⊆ attrB

! is a completely different operator (logical NOT), so I don't see it as
being an issue that those two expressions aren't equivalent.

It'd be great to use the proper set operators everywhere in FreeRADIUS, 
but I imagine the majority of users wouldn't have a clue what they meant.
So we do the automatic translation based on the types of the operands.

We already translate < to mean subset when applying to IP ranges.

i.e. 192.168.0.1 < 192.168.0.0/24 Is true.

I see this as another case of needing to do the implicit conversion from 
well known comparison operators to set theory operators.

>> First one is true if any of the attributes doesn't match the regex, the
>> second one if none of the attribute match the regex. I would expect them
>> to return the same. There might be some rule or lemma in mathematical
>> set theory here, but I'm not really sure about that (especially since
>> that would probably require explicit any/all-modifiers).
> 
>  I'll try to remember my math.  I'm sure I had this in one of my degrees.

I didn't cover it when I studied set theory, but that was really set theory
light.

>> About a year ago I was working on a small filtering language for an API
>> which required multi-valued attributes. We changed the use of >, <, <=
>> and >= to yield to syntax errors when combined with multi-valued
>> attributes, because nobody here really knew what they were supposed to
>> do in this context.
> 
>  Makes sense.

You can apply the same logic I described previously to any operator, and
you'll get consistent and understandable results.

Arran Cudbard-Bell <a.cudbardb at freeradius.org>
FreeRADIUS development team

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 881 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20140731/ff3577f4/attachment.pgp>


More information about the Freeradius-Users mailing list