Inconsistent escaping of regex parentheses

[Alan DeKok]

On Jan 20, 2020, at 1:20 PM, Tim <tim at 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.