On 01/15/2015 04:45 AM, Arran Cudbard-Bell wrote:
On 7 Jan 2015, at 20:07, Nikolai Kondrashov <Nikolai.Kondrashov@redhat.com> wrote:
Hi Alan,
On 12/09/2014 03:02 PM, Alan DeKok wrote:
On Dec 9, 2014, at 6:51 AM, Nikolai Kondrashov <Nikolai.Kondrashov@redhat.com> wrote:
They have noticed that binary LDAP values get truncated on embedded zero characters (\0) in RADIUS replies, in radiusReplyMessage in particular. I.e. for
Arran and I have spent the last two weeks fixing those issues. The server *never* dealt well with embedded zeros in “string” data. Octets, yes. Strings, no.
We already have an integration test for strings with embedded zeros. We would like to add a test for zeros in "binary" attributes.
I'm not sure exactly what you mean by octets here. Is it attributes with "octets" type in dictionaries? If so, are LDAP attributes supposed to contain hex strings for them, and it is basically "00" bytes which were the problem? Or could there be a direct binary representation for "octets"?
IIRC there's still issues with embedded zeroes in string attributes, because they were going via pairparse value. I don't know if Alan fixed this, if he didn't, i'll try and get it sorted for 3.0.8.
To test, insert binary data (with embedded zeroes) into any string attribute in LDAP then map the string attribute to an octets type attribute in the server.
You should see that the entire attribute value is copied, embedded zeroes and all.
Previously the copy would have stopped at the first embedded zero.
Is the "abinary" type affected?
abinary is ascend binary filters. It's a way of packing filtering rules into a binary blob. abinary is expected to be in its presentation format (text) when entering the server from any route other than the RADIUS decoder, so no.
Could you perhaps suggest attribute names/types and LDAP attribute values to test for?
See above.
Thanks, Arran! We've postponed the binary value testing for now, but I think we'll get around to it. I'll forward this to our QE guy. Nick