tools: a non-admin may reach their own session directory
A non-admin was confined to user_data/<user_id>/ alone, which made four
tools reject the directory the user's own uploads land in: share_file
refused the file it was asked to send back, filesystem could not read it,
and terminal/code_exec could not be pointed at it. In a prod session the
agent worked around the refusal by copying the uploaded file into its
sandbox with code_exec — the very bypass the injected security policy
forbids — and the copy collided with a same-named file, so the user got a
link to Project_1.mp3 instead of their own upload, plus an 8.6 MB duplicate.

navi/tools/_internal/areas.py now names the two roots a user owns, and the
four call sites share it. Relative paths still resolve into the sandbox,
and each tool keeps its own way of refusing: terminal returns
sandbox_violation, code_exec silently falls back to the sandbox root. The
share_file refusal lists both roots instead of "outside user sandbox", so
the agent retries in the right one instead of routing around it.

The session directory belongs to the same user: its id arrives from the
runtime context, never from tool arguments, and only the session's owner
can open it.
1 parent 41e143e commit f9a49ba9350d6f2fdd2d4f26e8403d166579f416
@Eugene Sukhodolskiy Eugene Sukhodolskiy authored 1 hour ago
Showing 16 changed files
View
docs/mechanics.md
View
manuals/code_exec.md
View
manuals/filesystem.md
View
manuals/share_file.md
View
manuals/terminal.md
View
navi/core/context_builder.py
View
navi/tools/_internal/areas.py 0 → 100644
View
navi/tools/code_exec.py
View
navi/tools/filesystem.py
View
navi/tools/share_file.py
View
navi/tools/terminal.py
View
tests/unit/tools/test_areas.py 0 → 100644
View
tests/unit/tools/test_code_exec.py
View
tests/unit/tools/test_filesystem.py
View
tests/unit/tools/test_share_file.py
View
tests/unit/tools/test_terminal.py