security: harden solver execution gates and 94-test suite

[brightyorcerf]

Linked issue

• Closes [Bug]: Unvalidated subpath injection in solver execution and data-generation routes #451
• Related Fix case-run path traversal #431, fix: sanitize dzuuid to prevent path traversal in /uploadCase (#254) #434, Absorb MUIO v5.5 changes #422

Existing related work reviewed

• Issues/PRs reviewed: Fix case-run path traversal #431, fix: sanitize dzuuid to prevent path traversal in /uploadCase (#254) #434, Absorb MUIO v5.5 changes #422, Fix path traversal vulnerability by validating dzuuid and chunk param… #256

Overlap assessment

• Classification: Security Hardening / Stability
• Overlapping items: Filesystem path validation logic and Config.validate_path implementation.
• Why this is not duplicate/superseded: While Fix case-run path traversal #431 and fix: sanitize dzuuid to prevent path traversal in /uploadCase (#254) #434 address path traversal at the "Passive Route" level (Data at rest: Uploads, Downloads, Deletions), this PR targets the "Active Execution" surface. Specifically, Fix case-run path traversal #431 secures file retrieval, but fails to validate caserunname in routes where it flows into subprocess.run() arguments (most notably /run and /batchRun. This PR introduces a comprehensive _validate_case_inputs framework that closes the Remote Code Execution (RCE) and Arbitrary File Write gaps that existing PRs have left exposed. Furthermore, this PR includes a full security regression suite (94 tests) ensuring these execution gates remain hardened against future regressions) a level of validation not present in previous submissions.

Why this PR should proceed

• Patches a Critical Security Vulnerability: The v5.5 upstream sync introduced/modified several routes in DataFileRoute.py that failed to validate the caserunname input against path traversal. Because this value ultimately flows into subprocess.run() arguments for solver execution (in the /run endpoint), an attacker could escape the designated res/ sandbox (caserunname: "../../../../tmp/evil") and run shell processes from arbitrary directories, posing a severe system security risk.

• Zero Regressions & Strong Test Coverage: Adds 94 new test cases specifically targeting traversal payloads (including null-byte injection) across all 12 affected route handlers. The entire existing test suite continues to pass. This PR also thoroughly enforces Config.validate_path() across all APIs that handle data files.

Summary

What changed:

• Introduced the _validate_case_inputs() helper in DataFileRoute.py to consistently validate both casename and caserunname at the route boundary before any filesystem access or instantiation.
• Applied the new path validation helper to 12 endpoints (including /generateDataFile, /createCaseRun and so on).
• Implemented a strict whitelist ({'glpk', 'cbc'}) for the solver parameter in the /run endpoint to prevent command/solver injection.
• Fixed a swallowed exception bug in /deleteCaseRun by placing the PermissionError handler before its parent class (OSError), ensuring path validation failures return a 400 instead of a generic 500.
• Added a comprehensive test suite (tests/test_path_traversal.py) with 94 tests verifying path traversal protections.

Why:

• Previously, while casename was somewhat protected by the DataFile() constructor inheriting Osemosys.__init__, caserunname was completely ignored. A request constructed with a safe casename but a malicious caserunname (e.g., ../../../../etc/passwd) would successfully bypass checks and traverse the filesystem. Validating both inputs exactly at the route entry point eliminates this gap.

Validation

• Tests added/updated (or not applicable)
• Validation steps documented
• Evidence attached (logs/screenshots/output as relevant)

Documentation

• Docs updated in this PR (or not applicable)
• Any setup/workflow changes reflected in repo docs

Scope check

• No unrelated refactors
• Implemented from a feature branch
• Change is deliverable without upstream OSeMOSYS/MUIO dependency
• Base repo/branch is EAPD-DRB/MUIOGO:main (not upstream)

Exception rationale

blank

[SeaCelo]

Thanks for this. We're prioritizing other work right now, so converting this to draft for the time being. We'll revisit when we're ready to pick these up.