zerto_recover_file took a dest_dir parameter, built a path from it with no
containment check, created that directory, and wrote the recovered bytes
there. It also passed the same string to the appliance as
initialDownloadPath.
On one developer's laptop that reads as "write to my own disk". The moment
this server is shared it is an arbitrary write, and a caller-supplied path
handed to another system is worse than it looks: a UNC path from a
domain-joined appliance is an outbound authentication attempt.
The parameter is gone. The destination now comes from config only, so the
caller can influence neither where bytes land nor where the ZVM mounts.
Returning a path was also useless to a remote caller. A path on this host
means nothing on theirs, so the whole recover half of the loop would have
quietly stopped working the first time this was hosted. The tool now
returns the content: text where it decodes as UTF-8, base64 otherwise,
with the byte count and a sha256 so the caller can verify what they got.
Files over max_recover_bytes (1 MiB default) are refused and pointed at
the whole-VM ladder instead of streamed through a tool result. FLR is for
a config file or a dropped directory.
Verified live against ZVM 10.9.10: jp-ubuntu returned 158 bytes and ad1
returned 164, both as text with matching content, both sessions
unmounted, and dest_dir no longer appears in the advertised tool schema.
pytest 51 passed (3 new, including one asserting the parameter set so the
caller-supplied destination cannot come back by accident).
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_016yVfC5nvZowoLFnEGWhLGn
justinandClaude Opus 5
claude