Hi, I have two servers, one here (in my office, with CentOS 6.5) and one at another facility (with RHEL 6.5). Both are running FreeRADIUS 3.0.4 rc 1 from what I can establish. I have these attributes in my reply: MS-MPPE-Encryption-Policy = Encryption-Required MS-MPPE-Encryption-Types = 4 MS-MPPE-Send-Key = 0xf1ad6cfa6e603b2bdb8480bd7ac84239 MS-MPPE-Recv-Key = 0x6cfc74047d13c6efa111a66fd9e360f4 EAP-Message = 0x03020004 Message-Authenticator = 0x00000000000000000000000000000000 SAML-AAA-Assertion = '<saml:Assertion xmlns:saml=\"urn:oasis:names:tc:SAML:2.0:assertion\" IssueInstant=\"2014-08-22T13:48:00\" ID=\"e9e79e59-9fb5-4b4e-b8c6-a4ef77559516\" Version=\"2.0\">' SAML-AAA-Assertion = '<saml:Issuer>urn:mace:ac.uk:diamond.ac.uk</saml:Issuer>' SAML-AAA-Assertion = '<saml:AttributeStatement><saml:Attribute NameFormat=\"urn:oasis:names:tc:SAML:2.0:attrname-format:uri\" Name=\"urn:oid:1.3.6.1.4.1.5923.1.1.1.7\">' SAML-AAA-Assertion = '<saml:AttributeValue>sysdev</saml:AttributeValue>' SAML-AAA-Assertion = '</saml:Attribute></saml:AttributeStatement></saml:Assertion>' In the server config in my office, I can use the below expression: if ("%{reply:SAML-AAA-Assertion[*]}" =~ /("urn:oid:1\.3\.6\.1\.4\.1\.5923\.1\.1\.1\.7")((\n|.)*?)(<saml:AttributeValue>)(\n*)(.*?)(\n*)(<\/saml:AttributeValue>)/) { : } This happily resolves to TRUE on the local server. However, on the second server, it resolves to FALSE, and I have to use the below there: if ("%{reply:SAML-AAA-Assertion[*]}" =~ /(urn\:oid\:1\.3\.6\.1\.4\.1\.5923\.1\.1\.1\.7)((\n|.)*?)(\<saml\:AttributeValue>)(\n*)(.*?)(\n*)(\<\/saml\:AttributeValue>)/) { : } The two regular expressions are the same with the following exceptions: All colons are escaped, all greater-as and smaller-as signs are escaped, and apparently the other server does not like having the quotes in the first regex group, even when escaped, or when using the \Q and \E modifiers before and after. According to several regex tests, the above should be ok, so... question to you regular expression whizzes and to Arran and Alan is: Why does the former not work on the second server? It seems the un-escaped colons and the quotes trip the regex up even though it should be ok? Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 Janet, the UK's research and education network. Janet(UK) is a trading name of Jisc Collections and Janet Limited, a not-for-profit company which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238
Is one compiled against pcre and the other against stock POSIX libs? See ldd/the top of the debugging -X output. -- Sent from my mobile device, please excuse brevity and typos
Arran has pushed a fix which should help.
Thank you, Alan (and Arran). Stefan Janet(UK) is a trading name of Jisc Collections and Janet Limited, a not-for-profit company which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238
On 31 Aug 2014, at 17:32, Alan DeKok <aland@deployingradius.com> wrote:
Stefan Paetow wrote:
I have two servers, one here (in my office, with CentOS 6.5) and one at another facility (with RHEL 6.5). Both are running FreeRADIUS 3.0.4 rc 1 from what I can establish.
Arran has pushed a fix which should help.
The string used the the value comparisons is a verbatim copy of the buffer of the attribute used in the regex. Not currently possible to do this for xlat, as the code isn't \0 safe. Need to audit paircmp_value and paircmp_op for \0 safety, but as you're probably not matching on binary data, it won't matter. Means you don't have to do contorted escaping. Just assume the raw value will get passed unmolested to the regex functions. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Arran Cudbard-Bell wrote:
The string used the the value comparisons is a verbatim copy of the buffer of the attribute used in the regex.
This will be noted in the next release...
Not currently possible to do this for xlat, as the code isn't \0 safe.
Yeah, that code is ancient. It really needs to be moved to something else... like the new template functionality. i.e. the xlat's should really return a template. But that's getting into implementation details.
Need to audit paircmp_value and paircmp_op for \0 safety, but as you're probably not matching on binary data, it won't matter.
According to the RFCs, strings SHOULD NOT have embedded zeros in them. But who reads the RFCs?
Means you don't have to do contorted escaping. Just assume the raw value will get passed unmolested to the regex functions.
Which is much easier, and less confusing than the previous behavior. But it *is* a change of behavior. And people will need to be aware of it. Alan DeKok.
participants (5)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Arran Cudbard-Bell -
Phil Mayers -
Stefan Paetow