Summary
internal/filesystem.FSToTar follows symlinks with filepath.EvalSymlinks and walks the resolved target without enforcing a project-root boundary. Builders that use filesystem.WithSymlinkBasePath can therefore stage readable files outside the project.
Required changes
Add a project-root boundary for followed symlinks during filesystem tar staging. Preserve valid symlinks that resolve within the project, including documented sibling-crate sharing. Reject or exclude symlinks that resolve outside the project root.
Pass the real project-root path through the relevant build and tar-staging APIs. Do not use the function directory as the boundary because functions can intentionally link to sibling project directories.
Rationale
The Rust builder newly uses the shared staging behavior. KCL and Go-templating builders already use it, and their staged files can be included in published image layers. This issue requires a shared fix rather than a Rust-specific restriction.
Affected areas
internal/filesystem tar and symlink handling- Build-context plumbing that can provide the real project-root path
- Function builders that use
filesystem.FSToTar with filesystem.WithSymlinkBasePath
Acceptance criteria
- A followed symlink cannot cause files outside the project root to be added to a tar archive.
- Symlinks to locations inside the project root remain supported.
- A function can continue to share a crate from a sibling directory through an in-project symlink.
- Tests cover direct and nested external symlinks, in-project symlinks, and the sibling-crate workflow.
- The behavior applies consistently to Rust, KCL, and Go-templating staging paths.
Backlinks
Summary
internal/filesystem.FSToTarfollows symlinks withfilepath.EvalSymlinksand walks the resolved target without enforcing a project-root boundary. Builders that usefilesystem.WithSymlinkBasePathcan therefore stage readable files outside the project.Required changes
Add a project-root boundary for followed symlinks during filesystem tar staging. Preserve valid symlinks that resolve within the project, including documented sibling-crate sharing. Reject or exclude symlinks that resolve outside the project root.
Pass the real project-root path through the relevant build and tar-staging APIs. Do not use the function directory as the boundary because functions can intentionally link to sibling project directories.
Rationale
The Rust builder newly uses the shared staging behavior. KCL and Go-templating builders already use it, and their staged files can be included in published image layers. This issue requires a shared fix rather than a Rust-specific restriction.
Affected areas
internal/filesystemtar and symlink handlingfilesystem.FSToTarwithfilesystem.WithSymlinkBasePathAcceptance criteria
Backlinks