Avoid shell execution in ReadFileTool ranged reads#5268
Closed
petrmarinec wants to merge 1 commit into
Closed
Conversation
rohityan
added
the
needs review
Collaborator
|
Hi @petrmarinec , Thank you for your contribution! We appreciate you taking the time to submit this pull request. Your PR has been received by the team and is currently under review. We will provide feedback as soon as we have an update to share. |
Collaborator
|
Hi @wukath , can you please review this. |
Collaborator
|
Hi @petrmarinec , can you please resolve the branch conflicts. |
rohityan
added
request clarification
petrmarinec
force-pushed
the
fix-readfile-shell-injection
branch
from
5df3e52 to
38d8b80
Compare
Contributor
Author
Hi! done. |
petrmarinec
force-pushed
the
fix-readfile-shell-injection
branch
from
38d8b80 to
34b7c30
Compare
petrmarinec
force-pushed
the
fix-readfile-shell-injection
branch
from
34b7c30 to
af7289e
Compare
Contributor
Author
copybara-service Bot
pushed a commit
that referenced
this pull request
Jul 8, 2026
Merge #5268 ### Link to Issue or Description of Change **1. Link to an existing issue (if applicable):** - Related: #5267 **2. Or, if no issue exists, describe the change:** **Problem:** `ReadFileTool` handles ranged reads by building `cat -n '{path}' | sed -n ...` from the caller-supplied `path`, while full reads use `environment.read_file(path)` and Python slicing. Shell metacharacters in `path` are therefore interpreted by the shell in the ranged-read branch instead of being treated as a literal file path. **Solution:** Remove the shell-based ranged-read branch and reuse the existing Python file-read logic for all reads. This keeps ranged output behavior while eliminating the shell dependency from `ReadFileTool`. ### Testing Plan **Unit Tests:** - [x] I have added or updated unit tests for my change. - [ ] All unit tests pass locally. Passed locally in Linux Docker (`python:3.11-bookworm`): - `pytest tests/unittests/tools/test_environment_tools.py tests/unittests/tools/environment_simulation` - `pytest tests/unittests/tools` - Result: `1519 passed` **Manual End-to-End (E2E) Tests:** - [x] On unmodified `origin/main`, a ranged `ReadFileTool` call with a crafted path wrote a proof file in the working directory. - [x] After this patch, the same call returns `File not found: ...` and no proof file is written. ### Checklist - [x] I have read the [CONTRIBUTING.md](https://github.com/google/adk-python/blob/main/CONTRIBUTING.md) document. - [x] I have performed a self-review of my own code. - [ ] I have commented my code, particularly in hard-to-understand areas. - [x] I have added tests that prove my fix is effective or that my feature works. - [ ] New and existing unit tests pass locally with my changes. - [x] I have manually tested my changes end-to-end. - [x] Any dependent changes have been merged and published in downstream modules. ### Additional context This is a small fix that removes the shell-based ranged-read implementation and makes `ReadFileTool` use the same direct file-read path for both full reads and ranged reads. Co-authored-by: Shangjie Chen <deanchen@google.com> COPYBARA_INTEGRATE_REVIEW=#5268 from petrmarinec:fix-readfile-shell-injection 34b7c30 PiperOrigin-RevId: 944768002
Collaborator
|
Thank you @petrmarinec for your contribution! 🎉 Your changes have been successfully imported and merged via Copybara in commit 1ac6875. Closing this PR as the changes are now in the main branch. |
Contributor
Author
|
For attribution: this merged fix corresponds to Google OSS VRP report #497794205: |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Link to Issue or Description of Change
1. Link to an existing issue (if applicable):
2. Or, if no issue exists, describe the change:
Problem:
ReadFileToolhandles ranged reads by buildingcat -n '{path}' | sed -n ...from the caller-suppliedpath, while full reads useenvironment.read_file(path)and Python slicing. Shell metacharacters inpathare therefore interpreted by the shell in the ranged-read branch instead of being treated as a literal file path.Solution:
Remove the shell-based ranged-read branch and reuse the existing Python file-read logic for all reads. This keeps ranged output behavior while eliminating the shell dependency from
ReadFileTool.Testing Plan
Unit Tests:
Passed locally in Linux Docker (
python:3.11-bookworm):pytest tests/unittests/tools/test_environment_tools.py tests/unittests/tools/environment_simulationpytest tests/unittests/tools1519 passedManual End-to-End (E2E) Tests:
origin/main, a rangedReadFileToolcall with a crafted path wrote a proof file in the working directory.File not found: ...and no proof file is written.Checklist
Additional context
This is a small fix that removes the shell-based ranged-read implementation and makes
ReadFileTooluse the same direct file-read path for both full reads and ranged reads.