On Jan 20, 2020, at 1:20 PM, Tim <tim@yetanother.net> wrote:
I'm in the process of upgrading an old 2.2.0 installation of FreeRADIUS to a more sane 3.0.17 release (stock from current CentOS).
That's good, but 3.0.20 is available from our web site: http://packages.networkradius.com/
I've hit a problem while trying to migrate the MySQL module due to the way that regular expressions seem to be getting escaped, and was hoping someone could see if anything looks amiss.
We have a custom attribute, My-Regex-Pattern, that is defined as a simple string.
OK...
In this instance, the attribute is held within the radgroupcheck MySQL table with the following regex stored as a string:
@(.+\\.)?(DOMAIN1|DOMAIN2)$
That needs to be fixed. In v2, the regexes had all kinds of escaping issues. That has all been fixed in v3. You can just write a regex without multiple backslashes.
However, when that string is later expanded via Unlang, the escaping appears to break as the opening parentheses get escaped while the closing ones do not:
(1) if ( &control:My-Regex-Pattern && &User-Name =~ /%{control:My-Regex-Pattern}/i ) { (1) EXPAND %{control:My-Regex-Pattern} (1) --> @\(\.\+\\.)\?\(DOMAIN1|DOMAIN2)\$ (1) ERROR: @\(\.\+\\.)\?\(DOMAIN1|DOMAIN2)\$ (1) ERROR: ^ Pattern compilation failed: unmatched parentheses (1) ERROR: Failed retrieving values required to evaluate condition
I have no idea why that would happen. I can't recall anything in the server which escapes open brackets coming *from* SQL. What does the full debug log show? Alan DeKok.