regular expression error in 3.0.x not present in 3.0.6
I have a policy.d file containing a regular expression that works in 3.0.6 that I’ve tried with two different flavors. Both flavors load and work in 3.0.6 but error in the latest 3.0.x branch. Flavor1: simple_nt_regexp = "^([^\\\\]*)(\\\\(.*))$" Flavor2: simple_nt_regexp = "^([^\\\\]*)\\\\(.*)$” In 3.0.x from today: /opt/local/etc/raddb/policy.d/strip-user-domain[9]: Invalid regular expression: /opt/local/etc/raddb/policy.d/strip-user-domain[9]: ^([^\\]*)\\(.*)$ /opt/local/etc/raddb/policy.d/strip-user-domain[9]: ^ Pattern study failed: unknown or incorrect option bit(s) set /opt/local/etc/raddb/policy.d/strip-user-domain[10]: Invalid regular expression: /opt/local/etc/raddb/policy.d/strip-user-domain[10]: ^([^\\]*)(\\(.*))$ /opt/local/etc/raddb/policy.d/strip-user-domain[10]: ^ Pattern study failed: unknown or incorrect option bit(s) set Is there something obvious that I am missing? — Aaron
On 5 Mar 2015, at 16:49, Aaron Hurt via Freeradius-Devel <freeradius-devel@lists.freeradius.org> wrote:
I have a policy.d file containing a regular expression that works in 3.0.6 that I’ve tried with two different flavors. Both flavors load and work in 3.0.6 but error in the latest 3.0.x branch.
See this:
From: Alan DeKok <aland@deployingradius.com> Subject: Re: filter_username and regexps broken Date: 5 March 2015 16:37:54 GMT To: FreeRadius developers mailing list <freeradius-devel@lists.freeradius.org> Reply-To: FreeRadius developers mailing list <freeradius-devel@lists.freeradius.org>
On Mar 5, 2015, at 11:28 AM, Sam Hartman <hartmans@mit.edu> wrote:
I'm getting a request denied because the username matches \.\., but I don't see why that should be true
Edit radiusd.conf and set “correct_escapes = true”
Alan DeKok.
:-) Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet Lumen House, Library Avenue, Harwell Oxford, Didcot, OX11 0SG jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. Jisc Collections and Janet Ltd. is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under Company No. number 2881024, VAT No. GB 197 0632 86. The registered office is: Lumen House, Library Avenue, Harwell, Didcot, Oxfordshire, OX11 0SG. T 01235 822200.
The errors in the previous post were with ‘correct_escapes=true’ … when setting to false the compilation fails with another error because it thinks the ‘]' is being escaped: with correct_escapes=false /etc/raddb/policy.d/strip-user-domain[10]: Invalid regular expression: /etc/raddb/policy.d/strip-user-domain[10]: ^([^\]*)\(.*)$ /etc/raddb/policy.d/strip-user-domain[10]: ^ Pattern compilation failed: missing terminating ] for character class — Aaron
On Mar 5, 2015, at 10:52 AM, Stefan Paetow <Stefan.Paetow@jisc.ac.uk> wrote:
On 5 Mar 2015, at 16:49, Aaron Hurt via Freeradius-Devel <freeradius-devel@lists.freeradius.org> wrote:
I have a policy.d file containing a regular expression that works in 3.0.6 that I’ve tried with two different flavors. Both flavors load and work in 3.0.6 but error in the latest 3.0.x branch.
See this:
From: Alan DeKok <aland@deployingradius.com> Subject: Re: filter_username and regexps broken Date: 5 March 2015 16:37:54 GMT To: FreeRadius developers mailing list <freeradius-devel@lists.freeradius.org> Reply-To: FreeRadius developers mailing list <freeradius-devel@lists.freeradius.org>
On Mar 5, 2015, at 11:28 AM, Sam Hartman <hartmans@mit.edu> wrote:
I'm getting a request denied because the username matches \.\., but I don't see why that should be true
Edit radiusd.conf and set “correct_escapes = true”
Alan DeKok.
:-)
Stefan Paetow Moonshot Industry & Research Liaison Coordinator
t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet Lumen House, Library Avenue, Harwell Oxford, Didcot, OX11 0SG
jisc.ac.uk
Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. Jisc Collections and Janet Ltd. is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under Company No. number 2881024, VAT No. GB 197 0632 86. The registered office is: Lumen House, Library Avenue, Harwell, Didcot, Oxfordshire, OX11 0SG. T 01235 822200.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
On Mar 5, 2015, at 12:17 PM, Aaron Hurt via Freeradius-Devel <freeradius-devel@lists.freeradius.org> wrote:
The errors in the previous post were with ‘correct_escapes=true’ …
Then you shouldn’t need 4 backslashes in a row. It looks like your regular expression is wrong. Use fewer backslashes. Alan DeKok.
When old style domain names come into FR they seem to always contain two backslashes ‘DOMAIN\\username’ which is what I am attempting to match. In 3.0.6 it appears to work with 3 or 4 backslashes with correct_escapes=true but I cannot seem to get the same behavior out of 3.0.x from today. These both work on 3.0.6 but fail with "Pattern study failed: unknown or incorrect option bit(s) set” on "FreeRADIUS Version 3.0.8 (git #c00210c), for host i386-apple-darwin14.1.0, built on Mar 5 2015 at 10:00:20" simple_nt_regexp = "^([^\\\\]*)(\\\\(.*))$” simple_nt_regexp = "^([^\\\]*)(\\\(.*))$” When I try to reduce the slashes down further to 2 I get the following on 3.0.8 /opt/local/etc/raddb/policy.d/strip-user-domain[9]: Invalid regular expression: /opt/local/etc/raddb/policy.d/strip-user-domain[9]: ^([^\]*)(\(.*))$ /opt/local/etc/raddb/policy.d/strip-user-domain[9]: ^ Pattern compilation failed: missing terminating ] for character class Again, this is all with ‘correct_escapes=true’ in the radiusd config. Thank you again, Aaron
On Mar 5, 2015, at 11:21 AM, Alan DeKok <aland@deployingradius.com> wrote:
On Mar 5, 2015, at 12:17 PM, Aaron Hurt via Freeradius-Devel <freeradius-devel@lists.freeradius.org> wrote:
The errors in the previous post were with ‘correct_escapes=true’ …
Then you shouldn’t need 4 backslashes in a row. It looks like your regular expression is wrong.
Use fewer backslashes.
Alan DeKok.
Okay, so this may be an issue with libpcre in Yosemite … I rebuilt the same sources again with: --with-pcre-lib-dir=/usr/local/opt/pcre/lib/ --with-pcre-include-dir=/usr/local/opt/pcre/include/ to specifically point to the homebrew installed libpcre and I now get the same behavior as in 3.0.6 and the regular expressions are working. Sorry, and thank you for the assistance. — Aaron
On Mar 5, 2015, at 11:40 AM, FreeRadius developers mailing list <freeradius-devel@lists.freeradius.org> wrote:
When old style domain names come into FR they seem to always contain two backslashes ‘DOMAIN\\username’ which is what I am attempting to match. In 3.0.6 it appears to work with 3 or 4 backslashes with correct_escapes=true but I cannot seem to get the same behavior out of 3.0.x from today.
These both work on 3.0.6 but fail with "Pattern study failed: unknown or incorrect option bit(s) set” on "FreeRADIUS Version 3.0.8 (git #c00210c), for host i386-apple-darwin14.1.0, built on Mar 5 2015 at 10:00:20"
simple_nt_regexp = "^([^\\\\]*)(\\\\(.*))$” simple_nt_regexp = "^([^\\\]*)(\\\(.*))$”
When I try to reduce the slashes down further to 2 I get the following on 3.0.8
/opt/local/etc/raddb/policy.d/strip-user-domain[9]: Invalid regular expression: /opt/local/etc/raddb/policy.d/strip-user-domain[9]: ^([^\]*)(\(.*))$ /opt/local/etc/raddb/policy.d/strip-user-domain[9]: ^ Pattern compilation failed: missing terminating ] for character class
Again, this is all with ‘correct_escapes=true’ in the radiusd config.
Thank you again,
Aaron
On Mar 5, 2015, at 11:21 AM, Alan DeKok <aland@deployingradius.com> wrote:
On Mar 5, 2015, at 12:17 PM, Aaron Hurt via Freeradius-Devel <freeradius-devel@lists.freeradius.org> wrote:
The errors in the previous post were with ‘correct_escapes=true’ …
Then you shouldn’t need 4 backslashes in a row. It looks like your regular expression is wrong.
Use fewer backslashes.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
On 5 March 2015 17:40:51 GMT+00:00, Aaron Hurt via Freeradius-Devel <freeradius-devel@lists.freeradius.org> wrote:
When old style domain names come into FR they seem to always contain two backslashes ‘DOMAIN\\username’ That's just a printout escaping thing in debugging. It's really one \ in the packet, and thus \\ is sufficient to match it in the regex with correct escapes set to true. -- Sent from my mobile device, please excuse brevity and typos
On Mar 6, 2015, at 3:11 AM, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
On 5 March 2015 17:40:51 GMT+00:00, Aaron Hurt via Freeradius-Devel <freeradius-devel@lists.freeradius.org> wrote:
When old style domain names come into FR they seem to always contain two backslashes ‘DOMAIN\\username’ That's just a printout escaping thing in debugging. It's really one \ in the packet, and thus \\ is sufficient to match it in the regex with correct escapes set to true.
Good to know, thank you.
-- Sent from my mobile device, please excuse brevity and typos - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
The regexp will not compile with just 2 backslashes it seems to translate \\ to \ (correct) and then escapes out the following ] (not correct) Things do work however with 4 backslashes \\\\ in the policy.d configuration and oddly enough it also works with 3 backslashes \\\ … am I missing something here as to how correct_escapes is supposed to function? This isn’t really an issue as I can make it work and get the expected behavior. with correct_escapes = true In policy.d file: simple_nt_regexp = "^([^\\]*)\\(.*)$” In radiusd -X output: /etc/raddb/policy.d/strip-user-domain[9]: Invalid regular expression: /etc/raddb/policy.d/strip-user-domain[9]: ^([^\]*)\(.*)$ /etc/raddb/policy.d/strip-user-domain[9]: ^ Pattern compilation failed: missing terminating ] for character class
On Mar 6, 2015, at 10:08 AM, FreeRadius developers mailing list <freeradius-devel@lists.freeradius.org> wrote:
On Mar 6, 2015, at 3:11 AM, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
On 5 March 2015 17:40:51 GMT+00:00, Aaron Hurt via Freeradius-Devel <freeradius-devel@lists.freeradius.org> wrote:
When old style domain names come into FR they seem to always contain two backslashes ‘DOMAIN\\username’ That's just a printout escaping thing in debugging. It's really one \ in the packet, and thus \\ is sufficient to match it in the regex with correct escapes set to true.
Good to know, thank you.
-- Sent from my mobile device, please excuse brevity and typos - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
On Mar 6, 2015, at 11:25 AM, Aaron Hurt via Freeradius-Devel <freeradius-devel@lists.freeradius.org> wrote:
The regexp will not compile with just 2 backslashes it seems to translate \\ to \ (correct) and then escapes out the following ] (not correct)
I’ve pushed a fix. Alan DeKok.
Thank you, that does indeed correct the issue. Much appreciated.
On Mar 6, 2015, at 11:41 AM, Alan DeKok <aland@deployingradius.com> wrote:
On Mar 6, 2015, at 11:25 AM, Aaron Hurt via Freeradius-Devel <freeradius-devel@lists.freeradius.org> wrote:
The regexp will not compile with just 2 backslashes it seems to translate \\ to \ (correct) and then escapes out the following ] (not correct)
I’ve pushed a fix.
Alan DeKok.
On Mar 5, 2015, at 11:49 AM, Aaron Hurt via Freeradius-Devel <freeradius-devel@lists.freeradius.org> wrote:
I have a policy.d file containing a regular expression that works in 3.0.6 that I’ve tried with two different flavors. Both flavors load and work in 3.0.6 but error in the latest 3.0.x branch.
The v3.0.x branch should be compatible with the 3.0.6 config.
Flavor1: simple_nt_regexp = "^([^\\\\]*)(\\\\(.*))$"
Flavor2: simple_nt_regexp = "^([^\\\\]*)\\\\(.*)$”
Ugh. The “endless backslash” problem. I’d prefer to see the use of “correct_escapes”.
In 3.0.x from today:
/opt/local/etc/raddb/policy.d/strip-user-domain[9]: Invalid regular expression: /opt/local/etc/raddb/policy.d/strip-user-domain[9]: ^([^\\]*)\\(.*)$ /opt/local/etc/raddb/policy.d/strip-user-domain[9]: ^ Pattern study failed: unknown or incorrect option bit(s) set
From google: https://lists.openinfosecfoundation.org/pipermail/oisf-users/2012-July/00186...
Seen this error before. It turned out I used headers from 8.31, but linked against the distro libpcre.
I'm pretty sure you have either a typo in your --with-libpcre-* or you\ have multiple libpcre.so's of different versions in your ld path.
Is there something obvious that I am missing?
Don’t install multiple versions of the same library. It’s just a bad idea. Alan DeKok.
Hi,
I have a policy.d file containing a regular expression that works in 3.0.6 that I’ve tried with two different flavors. Both flavors load and work in 3.0.6 but error in the latest 3.0.x branch.
The v3.0.x branch should be compatible with the 3.0.6 config.
should be...but I think the issue is that if you upgrade a 3.0.5 or 3.0.6 (for example) to 3.0.7 then the configs arent touched and the latest option "correct_escapes = true" wont be defined in the config if its breaking peoples settings then the default behaviour needs to be the 'old way' if it isnt defined in the config (?) alan
On Mar 5, 2015, at 3:52 PM, A.L.M.Buxey@lboro.ac.uk wrote:
The v3.0.x branch should be compatible with the 3.0.6 config.
should be...but I think the issue is that if you upgrade a 3.0.5 or 3.0.6 (for example) to 3.0.7 then the configs arent touched and the latest option "correct_escapes = true" wont be defined in the config if its breaking peoples settings then the default behaviour needs to be the 'old way' if it isnt defined in the config (?)
The upgrades shouldn’t break peoples configurations. We do a fair amount of testing to be sure this is true. Whatever the value of “correct_escapes”, so long as you don’ change it, it’s fine. The problem comes with people using the fixed escaping style, and setting “correct_escapes = false”. I’m not sure how that happens, but it’s wrong. Alan DeKok.
participants (5)
-
A.L.M.Buxey＠lboro.ac.uk -
Aaron Hurt -
Alan DeKok -
Phil Mayers -
Stefan Paetow