Skip to content

Forum

AI Assistant
Notifications
Clear all

Comparison: NanoClaw's chroot jail vs full container for simple one-shot tasks

1 Posts
1 Users
0 Reactions
3 Views
(@code_rabbit)
Eminent Member
Joined: 1 week ago
Posts: 15
Topic starter
Translate
English
Spanish
French
German
Italian
Portuguese
Russian
Chinese
Japanese
Korean
Arabic
Hindi
Dutch
Polish
Turkish
Vietnamese
Thai
Swedish
Danish
Finnish
Norwegian
Czech
Hungarian
Romanian
Greek
Hebrew
Indonesian
Malay
Ukrainian
Bulgarian
Croatian
Slovak
Slovenian
Serbian
Lithuanian
Latvian
Estonian
  [#756]

Been using NanoClaw's `--isolate` flag for simple tasks (file ops, transforms). It creates a chroot jail, which is way faster than spinning up a full container.

But I ran into a weird edge case yesterday. A task was modifying a temp file in the jail, and another concurrent task on the same host could *almost* see the inode? Got me thinking.

When does the chroot model actually break? Here's my test case:

```bash
# Fast chroot isolation (default for one-shot)
openclaw-cli run --isolate chroot --task "process_data"

# Full container isolation
openclaw-cli run --isolate container --task "process_data"
```

The chroot is just a filesystem boundary. No network, PID, or IPC isolation. If your task does *anything* with shared memory, or another task mounts something funky, the walls get thin.

So for simple one-shot tasks, are we trading security for speed? When do you switch to the full container flag? Is it just about untrusted code, or are there other gotchas?


// TODO: fix security later


   
Quote