bug(policy): Windows drive and share roots are accepted as read_write paths #5302

User Story

I work on OpenShell's native Windows support and run the gateway with the built-in MXC driver on Windows 11 x64. While testing filesystem policies I found that a policy with read_write: ['C:/'] is accepted and the sandbox reaches Ready, while read_write: ['/'] is rejected as overly broad. This affects anyone who writes policies for Windows sandboxes and relies on the gateway to refuse write access to a whole filesystem.

Problem Statement

The gateway refuses a filesystem root as a read_write path, but it only recognises the POSIX spelling. / and // are rejected with "read-write path is overly broad". On a gateway running on Windows, the Windows spellings of a root are accepted:

• drive roots: C:/, C:\, c:/, and D:/ (accepted even though the host has no D: drive)
• the root of the current drive: \
• a verbatim drive root: \\?\C:\
• a share root: \\localhost\C$

The same paths are accepted when added to a running sandbox with openshell policy set, which reports the new policy version as loaded. C:/. and C:// also pass validation, then fail later during provisioning with an MXC error instead of a policy error.

validate_filesystem_paths in openshell-policy treats a path as a root only if nothing is left after trimming trailing /. The same function backs sandbox create, live policy updates and the supervisor's policy data check.

Impact / Why This Matters

A policy can ask for write access to a whole drive or share, and the gateway accepts it without a warning; the request is passed to the MXC driver. The overly-broad check exists to stop exactly this, so on Windows it gives a false sense of safety: a typo or an over-general path is not caught, and policy set can widen a running sandbox's policy the same way. Today the only safeguard is to review every Windows policy by hand.

Acceptance Criteria

• sandbox create with read_write set to any of C:/, C:\, c:/, D:/, C:/., C://, \, \\?\C:\, \\?\C:, \\.\C:\, \\localhost\C$ or \\?\UNC\server\share fails with InvalidArgument and "read-write path is overly broad", as / does today.
• policy set that adds any of those paths to a running sandbox is rejected the same way.
• A root is reported as overly broad whether the gateway runs on Windows or Linux.
• Narrower paths such as /tmp, C:/work/demo, \\?\C:\work and \\server\share\work, and read-only roots, are still accepted.

Reproduction Steps

1. On Windows x64, build the windows branch and start the gateway with the built-in MXC driver (OPENSHELL_COMPUTE_DRIVER=mxc, backend = "process_container", allow_driver_config = true). Register and select it with openshell gateway add and openshell gateway select.

2. Save this policy as root.yaml:

   version: 1
   filesystem_policy:
     include_workdir: false
     read_only: []
     read_write: ['C:/']

3. Run openshell sandbox create --name root-rw --no-tty --policy root.yaml with a short workload (I used cmd.exe /d /c echo hi through --driver-config-json).

4. Repeat step 3 with read_write: ['/'] for comparison.

5. Create a detached sandbox whose policy has read_write: ['C:/work/rw']. Then run openshell policy set <name> --policy <file> --wait with a policy whose read_write is ['C:/work/rw', 'C:/'].

Actual: step 3 succeeds and the sandbox reaches Ready. The same happens with C:\, c:/, D:/, \, \\?\C:\ and \\localhost\C$. Step 4 is rejected. Step 5 reports Policy version 2 loaded, and adding \ or \\?\C:\ the same way is also loaded.

Expected: steps 3 and 5 are rejected like step 4.

Environment

• OpenShell: openshell 0.1.5-dev.40+g5b9e5b91a (windows branch at 5b9e5b9)
• OS: Windows 11 Enterprise Insider Preview x64, build 28020, native
• Deployment: gateway with the built-in MXC driver, backend = "process_container", plaintext gateway on loopback

Logs

# read_write: ['C:/']
Created sandbox: b35v1
Phase: Ready

# read_write: ['/']
Error:   x code: 'Client specified an invalid argument', message: "policy contains unsafe content: read-write path is overly broad: /"

# policy set adding 'C:/' to a running sandbox
Policy version 2 submitted (hash: e59e8764afcd)
Policy version 2 loaded (active version: 2)