Repository navigation
Fix #159: Allow browsing home directory when running as root (WSL) - #284
zwanski-start wants to merge 1 commit into
Conversation
… lives under a blocked system path When the server runs as root (the default user in WSL), Path.home() is /root, which is in LINUX_BLOCKED, so the folder browser's default listing returned 403 and new projects could not be created. The same happened for homes under /var (e.g. /var/home/<user> on Fedora Silverblue). is_path_blocked() now exempts the user's own home directory (and anything inside it) from the platform system blocklist, while credential directories (~/.ssh, ~/.aws, ...) remain blocked unconditionally. A home of / is ignored so it cannot unblock the whole filesystem. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
🔍 QA report: ✅ PassedTester: Ada (cubefarm agent, in a fresh session) · Round: 1 · Author: Dennis The fix resolves #159: when the home directory sits under a blocked system path (/root in WSL, /var/home on Silverblue), the folder browser opens at home and projects can be created there, while system dirs (/etc, /var, /root for other users, /tmp) and credential dirs (~/.ssh, ~/.aws) stay blocked. I confirmed the bug on master, then exercised the fix end to end by running the server with HOME pointed at a real directory under /var and creating a project through the UI. The 5 new tests, ruff, the security suites, the other pytest files and the UI build all pass. The mypy errors and the 21 ws/devserver test failures are the same on master.
🧪 Commands run
No browser screenshots were taken in this round. Posted by cubefarm · merges automatically once GitHub's checks pass |
Closes #159
Problem
In WSL the default user is
root, soPath.home()is/root./rootis inLINUX_BLOCKED, and the folder browser's first call (GET /api/filesystem/listwith no path → home) returned 403 "Blocked access to restricted path: /root", so users couldn't pick a folder for a new project.projects.pyandscaffold.pyuse the sameis_path_blocked(), so creating a project under/root/...was also rejected. The same issue hits systems that keep homes under/var(e.g./var/home/<user>on Fedora Silverblue).Change (
server/routers/filesystem.py)get_system_blocked_paths) and home-relative credential dirs (get_sensitive_blocked_paths).is_path_blocked()now:~/.ssh,~/.aws, …) — even inside home./is ignored (get_browsable_home()returnsNone) so it can't unblock the whole filesystem.get_blocked_paths()(no other callers).Other users'
/rootstays blocked for non-root users, and only the home subtree of/varis opened up, not/varitself.Verification
test_filesystem_security.py(5 tests, monkeypatchesPath.home): root home browsable,/root/.sshstill blocked,/var/home/alicebrowsable while/varand/var/logstay blocked, regular user still blocked from/root//etc,HOME=/ignored.Path.homeset to/root:/rootgets past the blocklist, while/etcand/root/.sshstill return "Access to this directory is not allowed".ruff check .clean;python test_security.pypasses.test_ws_security.py/test_devserver_security.pyhave 21 failures that are already on master (same count with my change stashed). They're unrelated to this fix.Assumptions
autoforge --workspace, but the CLI has no such flag. The root cause is the home-directory default, not the workspace, so this PR doesn't add one.🤖 Generated with Claude Code