[drewrukin]

Configured destinations such as ../shared currently reject valid uploads because parent components in the base path are treated as an escape. Compare normalized remote POSIX paths relative to the configured base while continuing to reject paths outside it.

Add regression tests for valid parent-relative destinations and rejection of paths outside the configured base.

---

Was generative AI tooling used to co-author this PR?

• Yes — Codex (GPT-6)

Generated-by: Codex (GPT-6) following the guidelines

[potiuk]

Approving. Since this relaxes the destination-path check added in #67667, I checked that its security properties still hold.

The trusted input is destination_path, set by the Dag author. The untrusted input is the GCS object name, written by whoever can write to the bucket. The new check normalises both, requires the result to be inside the base (PurePosixPath.relative_to), and treats any remaining .. as an escape. So every object-name escape is still refused:

• ../x under dir, and ../../x under ..;
• .. under the login directory (.);
• an absolute object name under a relative base;
• a look-alike sibling (../shared-other/... when the base is ../shared), because paths are compared part by part, not as string prefixes.

The only behaviour change is on the trusted side: a configured base with parent components, such as ../shared, now works as intended. As before, the check is lexical, so symlinks on the remote SFTP server are out of scope, as they were for #67667.

---

Drafted-by: Claude Code (Opus 5.5); reviewed by @potiuk before posting