What happened
Both official E2B SDKs send the filesystem watch user through Basic authorization, but neither Dormice watch route reads or validates that identity. The watcher executor has no user parameter and starts every watcher as the default user.
Reproduction:
- Start a Docker sandbox through an official E2B SDK.
- Call
watchDir('/root', callback, { user: 'root' }) (or Python watch_dir('/root', user='root')).
- Observe watcher startup fail on permissions even though root was requested.
A second focused check is to request an unsupported username. Other filesystem operations reject it, while the watch request is accepted and silently runs as the default user whenever the path is accessible.
Expected: The watch runs as the requested supported user, and unsupported usernames are rejected consistently with other filesystem operations.
Actual: The authorization header is ignored and every watch runs as user.
Impact: Root watches of root-only trees fail, and permission-sensitive applications can establish a watch under a different identity from the one they requested, missing expected events.
Relevant code and contract:
packages/server/src/e2b/envd/watch.ts:105-168 starts streaming watches without extracting or validating the username; 235-263 does the same for polling watches.packages/server/src/executor/executor.ts:563-574 states that watchDir has no user option and always runs as user.packages/server/src/executor/docker.ts:1164-1210 starts inotifywait without a container user.e2b 2.31.0 makes WatchOpts extend FilesystemRequestOpts and sends authenticationHeader(..., opts.user); Python 2.31.0 exposes watch_dir(..., user=...) and sends the same authentication header.
dor doctor output
Not applicable — this is an E2B watch protocol/identity mismatch, not a host-readiness failure.
Environment
- Dormice commit:
4417ae14938273f5d937c476cf7cdc57e22e53a5
- SDKs checked:
e2b JavaScript and Python 2.31.0
- Executor: Docker + gVisor; route behavior also traceable with the fake executor
- Verification: official SDK wire trace and server/executor identity trace
What happened
Both official E2B SDKs send the filesystem watch
userthrough Basic authorization, but neither Dormice watch route reads or validates that identity. The watcher executor has no user parameter and starts every watcher as the defaultuser.Reproduction:
watchDir('/root', callback, { user: 'root' })(or Pythonwatch_dir('/root', user='root')).A second focused check is to request an unsupported username. Other filesystem operations reject it, while the watch request is accepted and silently runs as the default user whenever the path is accessible.
Expected: The watch runs as the requested supported user, and unsupported usernames are rejected consistently with other filesystem operations.
Actual: The authorization header is ignored and every watch runs as
user.Impact: Root watches of root-only trees fail, and permission-sensitive applications can establish a watch under a different identity from the one they requested, missing expected events.
Relevant code and contract:
packages/server/src/e2b/envd/watch.ts:105-168starts streaming watches without extracting or validating the username;235-263does the same for polling watches.packages/server/src/executor/executor.ts:563-574states thatwatchDirhas no user option and always runs asuser.packages/server/src/executor/docker.ts:1164-1210startsinotifywaitwithout a container user.e2b2.31.0 makesWatchOptsextendFilesystemRequestOptsand sendsauthenticationHeader(..., opts.user); Python 2.31.0 exposeswatch_dir(..., user=...)and sends the same authentication header.dor doctor output
Not applicable — this is an E2B watch protocol/identity mismatch, not a host-readiness failure.
Environment
4417ae14938273f5d937c476cf7cdc57e22e53a5e2bJavaScript and Python 2.31.0