(MODULES-1967) Parse escape sequences from iptables

[karmix]

Interpret escape sequences in all string arguments for iptables options.

[jonnytdevops]

Thanks for your efforts on this.

It's seems very risky to run this new backslash handling code through the entire rule, rather than just the comment block.

Perhaps you could re-write your PR by limiting your code to the --comment field?

Thanks!

[karmix]

That was my original intent, however, I found that there was no way to accomplish this without significant changes to the parser. The current parser extracts the hash keys from the value string, tokenizes the remaining values, then decides which token to assign to each key. It is not possible to tokenize arguments differently for each option, if you don't know which option you are trying to parse. We are left with a choice, either change the scan RE and affect tokenization for all options (risky), or rewrite the parser and try to translate the existing logic (affects a lot more, but would also address other open bugs).

Without a rewrite, the token RE needs to change; it is not possible to restructure the values after they are already split and put into the hash because the scan loses white space. After the scan RE is changed, the parser will assign hash values such as 'one " two', where previously it would only assign 'one '. If an option does not support escape characters in its strings, the token has too many characters, regardless of whether we interpret the escape sequences. We can't fix this case without a rewrite. If the option does support escape characters in its strings, the token is wrong until we interpret the escape characters.

The proper solution is to redesign the parser. That should involve some coordination. This change for the existing parser simply moves the bug to what I believe to be a smaller (probably non-existent) set of edge cases.

[jonnytdevops]

Hi Karmix,

Sorry about the long delay.

I think I'm prepared to merge your commit however it would be appreciated if you could update the code with a fairly detailed comment on what it's actually doing, as I'm finding it a bit tricky to follow (although I understand the purpose by reading the ticket).

Thanks

[karmix]

JT:

The past few days have been really busy for me. I just wanted to let you
know that I got your request, and I hope to look into it next week.

Thanks,
Doug
On Jun 3, 2015 5:32 AM, "JT (Jonny)" notifications@github.com wrote:

Hi Karmix,

Sorry about the long delay.

I think I'm prepared to merge your commit however it would be appreciated
if you could update the code with a fairly detailed comment on what it's
actually doing, as I'm finding it a bit tricky to follow (although I
understand the purpose by reading the ticket).

Thanks

—
Reply to this email directly or view it on GitHub
#513 (comment)
.

[karmix]

JT:

I have updated the comment for the main hash generation (and squashed the commit). Is this what you wanted?

Thanks,
Doug

[jonnytdevops]

Awesome, thanks!