Proposal: optional read containment for workspace-files (Remote reads outside the workspace)

[JanvanHout]

Version: observed on 0.1.7-rc.1; the same README text is on master (0.1.7-rc.2).

Current behaviour (documented): @deepseek-ai/dsh-api-workspace-files README, "Addressing and paths": "the service does not impose workspace containment on file reads". read, readBytes, stat and file changes accept absolute paths, and relative paths are resolved from the workspace root. So any Web client holding the auth cookie can page through any file the Host process can read, for example /proc/self/environ, the launch token, $DSH_HOME/sessions/**, or .credentials.yaml. sandbox-policy read-only restricts writes but not these reads. Directory list/changes are already workspace-scoped.

Why it matters: this is fine for the single-user loopback model. But dsh web is also run behind a reverse proxy, over SSH forwarding, or as a shared instance. There, the file preview API turns into "read anything the Host process can read, including the Host's environment variables". ui-deliverables injects workspaceFiles as a required service, so it cannot be disabled on its own. Operators must choose between losing deliverables and exposing the Host filesystem.

Proposal:

1. A config option on workspace-files, e.g. containment: 'workspace' | 'none', that applies the directory-listing rule (resolved path must remain inside the Session workspace root, symlinks resolved) to read/readBytes/stat/file changes and baseFile. Default none keeps today's behaviour; dsh web --host <non-loopback> could default to workspace.
2. Alternatively, an allow-list of extra roots (readRoots: string[]), so deliverables outside the workspace keep working.
3. Make workspaceFiles optional in ui-deliverables, so deployments can disable the service without breaking plugin activation (today the entry stays pending (waiting for service: workspaceFiles)).

A related question: session-reference states it "assumes its host is authorized to read every session". A note in SAFETY.md listing the services that assume a single trusted user (workspace-files, session-reference, session-log-download, terminal, plugin-manager) would help anyone running a shared instance.