fix(server): allow newlines in exec command arguments

[zanetworker]

Summary

Allow newline characters in sandbox exec command arguments so multi-line scripts (python3 -c "def f():\n ...", bash -c "echo 'line1\nline2'") work without base64 workarounds.

Related Issue

Fixes #1963

Changes

• shell_escape() (sandbox.rs): Remove newline rejection. Newlines inside POSIX single quotes are literal characters, not command separators. Null byte rejection preserved.
• validate_exec_request_fields() (validation.rs): Add reject_null_bytes() for exec command arguments instead of reject_control_chars(). Newline rejection preserved for workdir and environment values.

Testing

Verified end-to-end against a live gateway with podman driver on macOS:

$ openshell sandbox exec -n multiline-test -- python3 -c "
def hello():
    print('multi-line scripts work!')
hello()
"
multi-line scripts work!

• cargo test --package openshell-server — 857 tests pass, 0 failures
• Multi-line Python script via sandbox exec — works
• Multi-line bash script via sandbox exec — works
• Single-line commands — no regression
• Null bytes in args — still rejected
• Newlines in workdir — still rejected
• Newlines in env values — still rejected

Checklist

• Follows Conventional Commits
• Commits are signed off (DCO)
• Architecture docs updated (not applicable — no architectural change)

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[elezar]

nit: crates/openshell-server/src/grpc/validation.rs:57 still calls reject_control_chars() for exec environment values, but validate_exec_env_entries() below routes through validate_env_entries_inner() and checks env values again. Keeping the length check in the direct loop makes sense, but the control-char check could be left to the env-entry validator.

[TaylorMutch]

@zanetworker is this PR still active?

[zanetworker]

@TaylorMutch yes, applied the changes requested.

[TaylorMutch]

/ok to test 32add0c

[TaylorMutch]

Thanks for the updates. The core validation change looks sound, and the targeted tests pass locally. One requested change still appears to be missing from the current head (32add0ccc).

Now that command arguments may contain CR/LF, both command_preview logging paths in grpc/sandbox.rs log the assembled command without escaping it. In line-oriented log sinks, user-controlled newlines can split records or create forged-looking continuation lines. Please escape the preview in both relay paths, ideally through a shared helper:

let command_preview: String = command
    .chars()
    .take(120)
    .flat_map(char::escape_default)
    .collect();

Please also add the previously requested regression case combining CR/LF with an embedded single quote—for example, print('one')\r\nprint('two')—to verify multiline text composes correctly with POSIX single-quote escaping.

The latest commit message indicates these were addressed, but neither change appears in the current diff. Once those are included and CI passes, this should be ready for another review.

[TaylorMutch]

@zanetworker please have a look when you get a chance. Probably just the change above is needed then we can merge this in.

[zanetworker]

@TaylorMutch updated.

[TaylorMutch]

/ok to test zanetworker@e30ac3b