[Improvement-17994][Seatunnel] harden startupScript and -i args

[yzeng1618]

Purpose of the pull request

Harden startup script validation and fix -i variable quoting issues for the SeaTunnel task to prevent path traversal and shell injection. Also update outdated SeaTunnel task documentation.

Brief change log

• Add startupScript allowlist validation in SeatunnelParameters#checkParameters

• Add bash-safe quoting/escaping for -i variable values in SeatunnelTask

• Support values containing single quotes ' in -i parameters

Update SeaTunnel task docs (EN/ZH): refresh links to 2.3.12

Verify this pull request

This pull request is already covered by existing tests, such as:

• Unit tests in dolphinscheduler-task-plugin/dolphinscheduler-task-seatunnel: org.apache.dolphinscheduler.plugin.task.seatunnel.SeatunnelTaskTest (covers buildOptions() including config suffix detection, reading config from Resource Center, and -i parameter generation).

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

This PR does not contain incompatible changes.

Fix #17994

[boring-cyborg]

Thanks for opening this pull request! Please check out our contributing guidelines. (https://github.com/apache/dolphinscheduler/blob/dev/docs/docs/en/contribute/join/pull-request.md)

[SbloodyS]

Why change this? We support v2.3.3 at most for now.

[yzeng1618]

It seems that versions above SeaTunnel 2.3.3 should be supported for now. So I'll update it to the latest version 2.3.12. Please correct me if my understanding is wrong. Alternatively, I can temporarily revert it back to the original version.

[SbloodyS]

Please revert this since we don't didn't conduct a comprehensive compatibility test.

[yzeng1618]

Okay, it has been changed to 2.3.3.

[yzeng1618]

@SbloodyS Could you please help check the cause of the CI error? It seems the error isn’t related to my changes. Shall we retry it?

[SbloodyS]

@SbloodyS Could you please help check the cause of the CI error? It seems the error isn’t related to my changes. Shall we retry it?

I've restarted CI.

[SbloodyS]

LGTM

[fuchanghai]

LGTM

[fuchanghai]

should we add a UT to validate this method? cc @SbloodyS

example

  @Test
  public void testInvalidStartupScript() {
      assertFalse(isValidStartupScript("../../../etc/passwd"));
      assertFalse(isValidStartupScript("script.sh; rm -rf /"));
      assertFalse(isValidStartupScript("script"));  // no suffix
      assertFalse(isValidStartupScript(".sh"));     // no file name
  }

  @Test
  public void testQuoteForBash() {
      assertEquals("'value'", quoteForBash("value"));
      assertEquals("'abc'"'"'def'", quoteForBash("abc'def"));
      assertEquals("''", quoteForBash(null));
      assertEquals("'$(rm -rf /)'", quoteForBash("$(rm -rf /)"));
  }

[yzeng1618]

Thank you for your suggestion. It has been added.

[yzeng1618]

@SbloodyS Could you please help check the cause of the CI error? It seems the error isn’t related to my changes. Shall we retry it?

I've restarted CI.

Please trigger the CI again, thanks.

I noticed a workflow issue and would like to get your thoughts on it.

Currently, when a new PR is merged into the dev branch, all other PRs — even those that have already passed CI — are required to update their branches and re-run CI before they can be merged.

This means that even PRs unrelated to the recent changes must trigger CI again, which can:

• Increase unnecessary CI runs
• Consume additional CI resources
• Add extra operational overhead for contributors

I’m wondering whether we could consider a workflow similar to SeaTunnel:

• If there is a merge conflict with the latest dev, the contributor resolves the conflict and re-runs CI.
• If there is no conflict, re-running CI would not be required.

This might help reduce redundant CI executions and improve overall efficiency.

[SbloodyS]

Currently, when a new PR is merged into the dev branch, all other PRs — even those that have already passed CI — are required to update their branches and re-run CI before they can be merged.

This means that even PRs unrelated to the recent changes must trigger CI again, which can:

• Increase unnecessary CI runs
• Consume additional CI resources
• Add extra operational overhead for contributors

I’m wondering whether we could consider a workflow similar to SeaTunnel:

• If there is a merge conflict with the latest dev, the contributor resolves the conflict and re-runs CI.
• If there is no conflict, re-running CI would not be required.

This might help reduce redundant CI executions and improve overall efficiency.

The consensus of PMC/Committer in this community determines that contributors do not need to pay attention to it for the time being.

[sonarqubecloud]

Quality Gate passed

Issues
3 New issues
0 Accepted issues

Measures
0 Security Hotspots
80.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[SbloodyS]

+1

[fuchanghai]

+1

[boring-cyborg]

Awesome work, congrats on your first merged pull request!