fix: use 0o644 for inbound media files to allow sandbox read access by zerone0x · Pull Request #17943 · openclaw/openclaw

zerone0x · 2026-02-16T09:54:36Z

Summary

Inbound media files were saved with 0o600 permissions (-rw-------), making them unreadable from Docker sandbox containers running as different users.

Changes

Change file mode from 0o600 to 0o644 in saveMediaSource() and saveMediaBuffer()

Why 0o644?

Owner can read/write
Group and others can read (required for sandbox access)
The containing directory already uses 0o700, so only users with directory access can see filenames
Media files are not sensitive credentials — they're user-uploaded attachments

🤖 Generated with Claude Code

Greptile Summary

This PR changes media file permissions from 0o600 to 0o644 in saveMediaSource() (local file path) and saveMediaBuffer() to allow Docker sandbox containers running as different users to read inbound media files. The rationale is sound — media files are user-uploaded attachments (not credentials), and the parent directory already uses 0o700 to restrict directory-level access.

However, the fix is incomplete for URL-sourced media:

The downloadToFile helper at line 152 still uses createWriteStream(dest, { mode: 0o600 }). When saveMediaSource processes a URL, it calls downloadToFile to write a .tmp file, then renames it. Since fs.rename preserves permissions, the final file retains 0o600 — leaving URL-downloaded media unreadable from the sandbox.

Confidence Score: 2/5

This PR partially fixes the sandbox read-access issue but misses the URL download path, leaving the bug unfixed for a significant code path.
The two changed lines are correct on their own, but the downloadToFile function (line 152) was not updated, which means URL-sourced media still gets 0o600 permissions. This is a functional gap that undermines the stated goal of the PR.
src/media/store.ts — the downloadToFile function at line 152 still uses 0o600 and needs to be updated to 0o644.

_{Last reviewed commit: 7c006bb}

greptile-apps

_{1 file reviewed, 1 comment}

_{Edit Code Review Agent Settings | Greptile}

greptile-apps · 2026-02-16T09:57:26Z

Additional Comments (1)

src/media/store.ts
downloaded files via URL will keep 0o600 since fs.rename() preserves permissions

          const out = createWriteStream(dest, { mode: 0o644 });

_{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/media/store.ts
Line: 152:152

Comment:
downloaded files via URL will keep `0o600` since `fs.rename()` preserves permissions

```suggestion
          const out = createWriteStream(dest, { mode: 0o644 });
```

<sub>Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!</sub>

How can I resolve this? If you propose a fix, please make it concise.

greptile-apps

_{1 file reviewed, 1 comment}

_{Edit Code Review Agent Settings | Greptile}

greptile-apps · 2026-02-17T01:52:56Z

Additional Comments (1)

src/media/store.ts
URL downloads still use 0o600

The downloadToFile function still writes with mode: 0o600. When saveMediaSource handles a URL (the looksLikeUrl(source) branch at line 200), it calls downloadToFile which creates the .tmp file with 0o600, then renames it via fs.rename on line 211. Since rename(2) preserves file permissions, the final file retains 0o600 — defeating the purpose of this fix for URL-sourced media.

This should be updated to 0o644 as well, or a chmod should be added after the rename.

          const out = createWriteStream(dest, { mode: 0o644 });

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/media/store.ts
Line: 152:152

Comment:
**URL downloads still use `0o600`**

The `downloadToFile` function still writes with `mode: 0o600`. When `saveMediaSource` handles a URL (the `looksLikeUrl(source)` branch at line 200), it calls `downloadToFile` which creates the `.tmp` file with `0o600`, then renames it via `fs.rename` on line 211. Since `rename(2)` preserves file permissions, the final file retains `0o600` — defeating the purpose of this fix for URL-sourced media.

This should be updated to `0o644` as well, or a `chmod` should be added after the rename.

```suggestion
          const out = createWriteStream(dest, { mode: 0o644 });
```

How can I resolve this? If you propose a fix, please make it concise.

Inbound media files were saved with 0o600 permissions, making them unreadable from Docker sandbox containers running as different users. Change to 0o644 (world-readable) so sandboxed agents can access downloaded attachments. Fixes openclaw#17941 Co-Authored-By: Claude <noreply@anthropic.com>

…penclaw#17943) * fix: use 0o644 for inbound media files to allow sandbox read access Inbound media files were saved with 0o600 permissions, making them unreadable from Docker sandbox containers running as different users. Change to 0o644 (world-readable) so sandboxed agents can access downloaded attachments. Fixes openclaw#17941 Co-Authored-By: Claude <noreply@anthropic.com> * test(media): assert URL-sourced inbound files use 0o644 * test(media): make redirect file-mode assertion platform-aware * docs(media): clarify 0o644 is for sandbox UID compatibility --------- Co-authored-by: zerone0x <zerone0x@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com> Co-authored-by: Vincent Koc <vincentkoc@ieee.org>

…penclaw#17943) * fix: use 0o644 for inbound media files to allow sandbox read access Inbound media files were saved with 0o600 permissions, making them unreadable from Docker sandbox containers running as different users. Change to 0o644 (world-readable) so sandboxed agents can access downloaded attachments. Fixes openclaw#17941 * test(media): assert URL-sourced inbound files use 0o644 * test(media): make redirect file-mode assertion platform-aware * docs(media): clarify 0o644 is for sandbox UID compatibility --------- Co-authored-by: zerone0x <zerone0x@users.noreply.github.com> Co-authored-by: Vincent Koc <vincentkoc@ieee.org>

…penclaw#17943) * fix: use 0o644 for inbound media files to allow sandbox read access Inbound media files were saved with 0o600 permissions, making them unreadable from Docker sandbox containers running as different users. Change to 0o644 (world-readable) so sandboxed agents can access downloaded attachments. Fixes openclaw#17941 Co-Authored-By: Claude <noreply@anthropic.com> * test(media): assert URL-sourced inbound files use 0o644 * test(media): make redirect file-mode assertion platform-aware * docs(media): clarify 0o644 is for sandbox UID compatibility --------- Co-authored-by: zerone0x <zerone0x@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com> Co-authored-by: Vincent Koc <vincentkoc@ieee.org> (cherry picked from commit 376a52a)

…penclaw#17943) * fix: use 0o644 for inbound media files to allow sandbox read access Inbound media files were saved with 0o600 permissions, making them unreadable from Docker sandbox containers running as different users. Change to 0o644 (world-readable) so sandboxed agents can access downloaded attachments. Fixes openclaw#17941 Co-Authored-By: Claude <noreply@anthropic.com> * test(media): assert URL-sourced inbound files use 0o644 * test(media): make redirect file-mode assertion platform-aware * docs(media): clarify 0o644 is for sandbox UID compatibility --------- Co-authored-by: zerone0x <zerone0x@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com> Co-authored-by: Vincent Koc <vincentkoc@ieee.org>

openclaw-barnacle Bot added size: XS experienced-contributor labels Feb 16, 2026

greptile-apps Bot reviewed Feb 16, 2026

View reviewed changes

steipete closed this Feb 16, 2026

steipete reopened this Feb 17, 2026

greptile-apps Bot reviewed Feb 17, 2026

View reviewed changes

zerone0x force-pushed the fix/issue-17941-media-file-permissions branch from 7c006bb to 2776ab7 Compare February 17, 2026 19:11

This was referenced Feb 21, 2026

fix(sandbox): propagate docker.user to all exec commands dashed/openclaw#5

Open

fix(media): allow os.tmpdir() paths in sandbox media source validation dashed/openclaw#10

Closed

vincentkoc force-pushed the fix/issue-17941-media-file-permissions branch from 2776ab7 to 5947e94 Compare March 2, 2026 05:42

zerone0x and others added 3 commits March 1, 2026 21:56

test(media): assert URL-sourced inbound files use 0o644

69cb17c

test(media): make redirect file-mode assertion platform-aware

b88cc30

vincentkoc force-pushed the fix/issue-17941-media-file-permissions branch from c10b911 to b88cc30 Compare March 2, 2026 05:56

docs(media): clarify 0o644 is for sandbox UID compatibility

2bd9fbc

vincentkoc merged commit 376a52a into openclaw:main Mar 2, 2026
13 checks passed

github-actions Bot mentioned this pull request Mar 2, 2026

📡 Upstream Digest — 2026-03-02 06:46 UTC curtismercier/openclaw-mods#159

Open

zerone0x deleted the fix/issue-17941-media-file-permissions branch March 2, 2026 06:50

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

fix: use 0o644 for inbound media files to allow sandbox read access#17943

fix: use 0o644 for inbound media files to allow sandbox read access#17943
vincentkoc merged 4 commits intoopenclaw:mainfrom
zerone0x:fix/issue-17941-media-file-permissions

zerone0x commented Feb 16, 2026 •

edited by greptile-apps Bot

Loading

Uh oh!

greptile-apps Bot left a comment

Uh oh!

greptile-apps Bot commented Feb 16, 2026

Uh oh!

greptile-apps Bot left a comment

Uh oh!

greptile-apps Bot commented Feb 17, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

zerone0x commented Feb 16, 2026 • edited by greptile-apps Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Changes

Why 0o644?

Greptile Summary

Confidence Score: 2/5

Uh oh!

greptile-apps Bot left a comment

Choose a reason for hiding this comment

Uh oh!

greptile-apps Bot commented Feb 16, 2026

Uh oh!

greptile-apps Bot left a comment

Choose a reason for hiding this comment

Uh oh!

greptile-apps Bot commented Feb 17, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

zerone0x commented Feb 16, 2026 •

edited by greptile-apps Bot

Loading