Harden Python query runner sandbox#7757
Conversation
There was a problem hiding this comment.
Thanks for this PR! The sandbox fix is solid and the API choices are correct for our pinned RestrictedPython 8.1 (safer_getattr, guarded_setattr, full_write_guard all exist there).
One request: could you split this into two PRs? It bundles two distinct fixes:
- Sandbox escape (
getattr/setattr-> guarded, custom_write ->full_write_guard): ~5 lines, critical, low-risk - Broken access control (static -> instance methods, org/data-source has_access checks, passing the real user to run_query): larger behavioral change.
These are different CWE classes with different risk profiles. Splitting lets the critical sandbox fix merge fast without waiting on review of the access-control changes, and keeps revert boundaries clean. The tests already separate cleanly along the same line.
Minor note on the second one: _get_data_source relies on self._current_user; if it's ever None, user.org_id raises AttributeError which gets swallowed into a misleading "Wrong data source name/id" message. Worth confirming that path.
e232319 to
e044757
Compare
|
@zachliu
I also addressed the |
What type of PR is this?
Description
Hardens the Python query runner in two areas:
The RestrictedPython changes target the currently pinned RestrictedPython 8.1.
How is this tested?
Added regression tests for private attribute access, protected writes, organization isolation, inaccessible data sources, view-only behavior, and current-user propagation.
Test result: 23 passed in tests/query_runner/test_python.py. Ruff and Black checks pass.
Related Tickets & Documents
Related to #7684, specifically the RestrictedPython sandbox escape report. This PR does not close the issue because the issue tracks additional findings.
Mobile & Desktop Screenshots/Recordings (if there are UI changes)
N/A