Security: dynamic --upload / --output accept unsafe filesystem paths

[abhinavkale-dev]

While testing dynamic CLI methods in gws, I noticed runtime file-path inputs for --upload and --output are not consistently validated.

In the released version (gws 0.3.4), both flags accept unsafe absolute paths and proceed successfully.
For agent/LLM-driven usage, this creates a potential local file read/write surface.

Environment

• gws (affected): 0.3.4 (./.local/bin/gws)
• Verified with local patched build (not released): ./target/debug/gws (0.4.4)
• OS: macOS (Apple Silicon)

Repro (before fix)

./.local/bin/gws --version

./.local/bin/gws drive files create --upload /etc/hosts --dry-run
echo "exit=$?"

./.local/bin/gws drive files list --output /tmp/gws-proof.bin --dry-run
echo "exit=$?"

Actual behavior

Both commands succeed with exit=0, even when given absolute paths:

• --upload /etc/hosts
• --output /tmp/gws-proof.bin

Expected behavior

Unsafe runtime file paths should fail validation and exit early. The CLI should:

• reject absolute paths
• reject traversal (..)
• prevent canonical/symlink escapes outside the working directory
• apply the same path-safety checks across runtime entry points

Likely root cause

In core runtime flow:

• src/main.rs parses dynamic --upload / --output and passes them through
• src/executor.rs performs file reads/writes (tokio::fs::read, tokio::fs::File::create) without centralized ingress validation
• src/mcp_server.rs uses separate bespoke upload validation logic

So validation exists in some places, but is not consistently enforced at runtime ingress.

Suggested fix

Use shared validators in src/validate.rs and apply them consistently:

• validate_safe_input_file_path(...)
• validate_safe_output_file_path(...)

Apply in:

• src/main.rs: validate dynamic --upload / --output before execute_method(...)
• src/mcp_server.rs: reuse shared input-file validator for MCP upload

Verification (after local fix)

cargo build

./target/debug/gws drive files create --upload /etc/hosts --dry-run
echo "exit=$?"

./target/debug/gws drive files list --output /tmp/gws-proof.bin --dry-run
echo "exit=$?"

Observed after local fix:

• --upload fails validation (exit=1)
• --output fails validation (exit=1)
• unsafe absolute paths are rejected before execution

[abhinavkale-dev]

Implemented fix for this issue and pushed to my fork branch:

• Branch: abhinavkale-dev:path-hardening-upload-output
• Commit: 50a5d14
• Compare: main...abhinavkale-dev:cli:path-hardening-upload-output

I can’t open a PR because the repo currently restricts PR creation to collaborators:
“An owner of this repository has limited the ability to open a pull request to users that are collaborators on this repository.”

@jpoehnelt could you please open a PR from this branch (or cherry-pick commit 50a5d14)?

[jpoehnelt]

Can you open a pr now.

[abhinavkale-dev]

@jpoehnelt, Opened PR for this issue: #363

The final implementation is now executor-based on current main and covers:

• absolute path rejection for --upload / --output
• traversal rejection
• symlink escape and broken-symlink-prefix hardening
• rejection of existing non-regular --output targets
• safer upload/output file I/O at the execution boundary to reduce TOCTOU exposure

The original issue write-up mentions src/main.rs / src/mcp_server.rs, but the current fix is applied in the shared runtime path through src/executor.rs and src/validate.rs.

[jpoehnelt]

Closing — path validation is now implemented via validate_safe_output_dir() and validate_safe_dir_path() in validate.rs, used across helpers. See also encode_path_segment() and validate_resource_name() for URL safety.