Cloud-execution track · container build & rootless exec

Thin images. The stack lives on the mount.

The containers the Posit/EKS pods run are built here with rootless Podman . The rule that makes them portable is the rule the whole suite runs on: an image is Link 0′ — the borrowed layer — so it carries only the kernel-adjacent bits and the CVMFS client. R, its compiler, and every library resolve from /cvmfs/software.ndexr.io/…/current , never from the image. Nothing of the image's userland enters a loaded binary.

Image lifecycle

Build — rootless Podman / OCI

Images built unprivileged (rootless Podman), reproducibly. The build adds no compilers or libraries a session will link — those come from the mount.

Audit — the thin-image proof

Every stored image is checked the way the build chain checks a binary (§3): a loaded artifact's loader + RPATH must point at /cvmfs, never the image's /usr or /lib.

Push — registry.ndexr.io

Passing images are pushed to the private Podman registry, addressed by digest so a pod pulls the exact bytes that were audited.

Distribute — pods on EKS

cc.ndexr.io schedules the images as Posit pods; each pod mounts CVMFS via the CSI driver and enters the stack the one way (hpc-env.sh → ml R/…).

The thin-image policy (§2 / §3)

An image that bakes a library a session ends up linking reintroduces host leakage — the exact failure the CVMFS/prefix stack exists to prevent. Keep images minimal and let the mount do the work.

Link 0′ — the borrowed layer

The base image replaces the bare-metal host. It may contribute the kernel-adjacent bits and the CVMFS client; nothing else may end up in a loaded binary.

readelf proof on stored images

loader (PT_INTERP) and RPATH/RUNPATH of any executable/.so must be under /cvmfs. A host/image path means the image is contaminated — rebuild, don't ship.

No LD_LIBRARY_PATH crutch

The stack is RPATH-only by design. An image that sets LD_LIBRARY_PATH to make something load is masking a contamination bug — report it, don't ship it.