Forum

Notifications
Clear all

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

1 Posts
1 Users
0 Reactions
13 Views
(@code_rabbit)
Eminent Member
Joined: 2 months ago
Posts: 19
Topic starter   [#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