[Fix-18217][DataX] Escape single quotes in custom parameters

[richardmilles]

Was this PR generated or assisted by AI?

Yes, assisted by AI.

Purpose of the pull request

Fixes #18217

Replaces #18466 (closed for missing PR template).

Custom DataX -D parameter values that contain single quotes break the generated shell command.

Brief change log

• Escape single quotes in DataX custom parameter values
• Add unit coverage for the escaping behavior

Verify this pull request

This change added tests and can be verified as follows:

• Run the DataX-related unit tests covering custom parameter escaping

Pull Request Notice

Pull Request Notice

If your pull request contains incompatible change, you should also add it to docs/docs/en/guide/upgrade/incompatible.md

[nikhiln64]

I dug into this with a shell and I think the escaping does not do what it is meant to, and also does not close the injection it is aimed at, because of the quoting context it lands in. CUSTOM_PARAM is -D%s='%s' and the whole set is wrapped in -p "...", so each value sits single quoted inside an outer double quoted block. The ''' idiom is the right escape when the value is inside a single quoted shell string, but here the surrounding quotes are the double quotes of -p "...", and inside double quotes a single quote is an ordinary character and a backslash before a single quote is literal too.

Running the exact string the builder produces for AND create_data > '2026-05-06 10:59:09' through sh, the argument that reaches DataX comes out as -Dds_incr_condition='AND create_data > '''2026-05-06 10:59:09'''' with the backslashes and doubled quotes intact, rather than the original value, so the escape corrupts the parameter instead of preserving it. The added test only asserts the assembled command string, never that a shell parses it back, which is why it passes green while the round trip is wrong. A test that runs the built command through sh and checks the value DataX actually receives would catch it.

The second half is that escaping only the single quote leaves the characters that actually break the outer double quoted block untouched. I tested a value of x"; some_command; echo " and the injected command ran, because the double quote closed the -p " block and the rest was interpreted by the shell, so as it stands the change does not reach its shell safety goal. The robust fix is usually to stop hand quoting and pass parameters as separate argv entries, or to single quote the whole value once with the standard ''' escape and drop the outer per value single quotes, so there is one quoting layer to reason about. Happy to help think it through, I have been in this same file on 18434.