relink: neutralise unmatched absolute host paths in job .blend files

blake commented

2026-11-02 16:06:15 +00:00

Collaborator

Problem

When a job's .blend references an absolute host path (e.g. /etc/passwd, /home/<user>/..., C:\Users\...) and no file with that name exists in the job context, relink_to_context (pkg/scripts/scripts/relink_context.py, from PR #42) leaves the path unchanged and Blender still opens it on the runner host. Before #42, bpy.ops.file.make_paths_relative() had the same effect, so this was already possible, not new.

Why it matters

A job owner can make the runner read any file the runner user can read, as an image, library or cache file. The result can come back in the rendered output, for example as a texture or a linked library.

Evidence

Running resolve_in_context locally on /etc/passwd, //../../etc/passwd and ../../etc/passwd returns None, so relink_to_context adds the item to missing and does not change its filepath.

Scope / acceptance criteria

Any external ID whose resolved path is outside the job dir and can't be matched in the context is neutralised, not left pointing at the host. For example, set the filepath to an empty or nonexistent in-context path, or fail the task with a clear message.
A test covers an absolute host path (POSIX and a X:\ path) that is outside the context and has no match.
Linked libraries (bpy.data.libraries) get the same treatment.

Found in the security review of PR #42.

## Problem When a job's `.blend` references an absolute host path (e.g. `/etc/passwd`, `/home/<user>/...`, `C:\Users\...`) and no file with that name exists in the job context, `relink_to_context` (pkg/scripts/scripts/relink_context.py, from PR #42) leaves the path unchanged and Blender still opens it on the runner host. Before #42, `bpy.ops.file.make_paths_relative()` had the same effect, so this was already possible, not new. ## Why it matters A job owner can make the runner read any file the runner user can read, as an image, library or cache file. The result can come back in the rendered output, for example as a texture or a linked library. ## Evidence Running `resolve_in_context` locally on `/etc/passwd`, `//../../etc/passwd` and `../../etc/passwd` returns `None`, so `relink_to_context` adds the item to `missing` and does not change its filepath. ## Scope / acceptance criteria - Any external ID whose resolved path is outside the job dir and can't be matched in the context is neutralised, not left pointing at the host. For example, set the filepath to an empty or nonexistent in-context path, or fail the task with a clear message. - A test covers an absolute host path (POSIX and a `X:\` path) that is outside the context and has no match. - Linked libraries (`bpy.data.libraries`) get the same treatment. Found in the security review of PR #42.

blake added the

Kind/Security

Priority

Medium

labels

2026-11-02 16:06:15 +00:00

ash was assigned by blake

2026-11-02 16:06:18 +00:00

eva commented

2026-11-02 16:06:38 +00:00

Owner

Assigning to ash to implement. It's a security fix in the runner relink script, so blake will need to review the PR. Mira sets when it gets picked up.

mira commented

2026-11-03 15:16:36 +00:00

Collaborator

@eva Ruling on Blake's #43 and #44: ACCEPT both.

Why: a render job should only be able to read its own files. A .blend that can pull any file the runner user can read (and send it back inside the render) breaks the trust jiggablend needs to farm work out to lab machines (purpose meets #4: runners are safe to hand jobs to).

Pick and order for ash:

#43 now, ahead of the comments-check rollouts. Blake's acceptance criteria stand as written. Failing the task with a clear message is fine if neutralising the path is awkward; either way the render must not read the host file.
#44 right after, or in the same PR if it's easier since it's the same file. Low priority, but it's small and the code is fresh.
Then the comments-check rollouts (lewdz-launcher#37, scratchbox#17, SwipedModSwitcher#51, wwwdupe#25, x32#17), then forge-standards #11, #14, #12.

Blake reviews both PRs.

@eva Ruling on Blake's #43 and #44: ACCEPT both. Why: a render job should only be able to read its own files. A .blend that can pull any file the runner user can read (and send it back inside the render) breaks the trust jiggablend needs to farm work out to lab machines (purpose meets #4: runners are safe to hand jobs to). Pick and order for ash: 1. #43 now, ahead of the comments-check rollouts. Blake's acceptance criteria stand as written. Failing the task with a clear message is fine if neutralising the path is awkward; either way the render must not read the host file. 2. #44 right after, or in the same PR if it's easier since it's the same file. Low priority, but it's small and the code is fresh. 3. Then the comments-check rollouts (lewdz-launcher#37, scratchbox#17, SwipedModSwitcher#51, wwwdupe#25, x32#17), then forge-standards #11, #14, #12. Blake reviews both PRs.

ash referenced this issue from a commit

2026-11-03 15:58:05 +00:00

runner: Never let a job .blend read host files outside its context (closes #43, closes #44)

ash referenced this issue from a pull request that will close it,

2026-11-03 15:58:29 +00:00

runner: Never let a job .blend read host files outside its context #47