createDirectories chmods pre-existing directories, breaking writeFile under /tmp and other system dirs

[andrewjamesbrown]

Summary

FilesystemAdapter.createDirectories issues chmod on every directory in the provided path, including pre-existing top-level directories like /tmp that the sandbox user does not own. This causes any writeFile whose parent is an existing system directory to fail.

This violates POSIX mkdir -p --mode semantics: chmod should only apply to directories the call actually created, never to pre-existing ones.

Version

@alibaba-group/opensandbox 0.1.7 (also reproduced visually in 0.1.5 / 0.1.8 per maintainers of a downstream SDK).

Reproduction

const sandbox = await client.createSandbox({ image: 'ubuntu:22.04' /* default user not root */ });
// /tmp exists in the image, owned by root, 1777 perms
await sandbox.files.writeFiles([{ path: '/tmp/probe.txt', data: 'hello' }]);
// works, because writeFiles doesn't try to chmod /tmp

// But the typical "ensure parent then write" pattern fails:
await sandbox.files.createDirectories([{ path: '/tmp' }]);
// → SandboxApiException: error accessing file: chmod /tmp: operation not permitted
//   at FilesystemAdapter.createDirectories (dist/chunk-UTFOITR4.js:686)

Expected

createDirectories([{ path: '/tmp' }]) against an existing /tmp should be a no-op (idempotent, like mkdir -p). Chmod should only be applied if the call actually creates a directory.

Actual

The adapter unconditionally chmods every path component, regardless of whether it already existed. When the sandbox process lacks permission to chmod a pre-existing component (the common case for /tmp, /var, /etc, /usr), the entire call fails — even though no directory needed to be created.

Impact

• Any downstream SDK that calls createDirectories defensively (to ensure a parent exists before writeFiles) breaks for paths under any system-owned directory.
• The error message — chmod /tmp: operation not permitted — reads like a sandbox-config issue and is misleading. The actual cause is createDirectories doing more than it should.

Suggested fix

In createDirectories, only chmod directories that were actually created in this call (i.e., the ones that did not exist before). Skip chmod for any path component that already exists with adequate perms.

Workaround (in our downstream SDK)

We've shipped a "lazy ensureDir" pattern: try writeFiles first; only call createDirectories if that fails (typical case: parent missing). This avoids the redundant createDirectories call entirely when the parent exists, sidestepping the bug. It's not a real fix though — nested writes under /tmp/missing/dir/file still hit the issue because createDirectories would attempt to chmod /tmp even when only creating /tmp/missing/dir.

Happy to send a PR if it would help.

[Pangjiping]

Root cause identified — two bugs in components/execd/pkg/web/controller/utils.go:

1. MakeDir unconditionally calls ChmodFile after MkdirAll, even when the directory already existed. For pre-existing system dirs like /tmp (owned by root), non-root sandbox users get EPERM.

2. SetFileOwnership defaults to os.Chown(path, os.Getuid(), os.Getgid()) when no owner/group is specified — forcing a chown that fails on dirs the current user doesn't own.

Fix in #1025:

• MakeDir: check existence via os.Stat before MkdirAll, only ChmodFile on newly created dirs
• SetFileOwnership: return nil when both owner and group are empty