On Sun 21-06-26 21:39:32, Farid Zakaria wrote:
> Currently, standard ELF and ELF FDPIC loaders require a fixed, absolute
> path to the dynamic linker/interpreter (specified via PT_INTERP). This
> creates significant inflexibility for relocatable dynamic interpreters,
> where binaries are packaged independent of global system paths.
>
> The primary goal of this patch series is to support relocatable binaries
> in Nix, where packages are stored in a read-only store (typically /nix/store).
> Allowing the ELF interpreter path to be resolved dynamically relative to
> the binary's location via $ORIGIN enables Nix packages to be relocated
> without needing patchelf or wrapper scripts.
>
> For details on the design and motivation for this in Nix, see:
> https://fzakaria.com/2026/06/21/nix-needs-relocatable-binaries
>
> This series introduces support for resolving the $ORIGIN placeholder in
> the ELF interpreter path, bringing the kernel's binary loading behavior
> in line with user-space dynamic linker origin resolution.
Thanks for the patches! Before dwelving into implementation details we
need to discuss whether something like this even belongs to the kernel.
Frankly to me this looks rather arbitrary and tied to the particular way
you've decided to setup your package management system. In particular the
usual answer for situations like these is to use namespaces which you
discount in your blog with: "If you are using tools like Bazel or Buck2
they likely already employ their own sandboxing via namespacing for builds.
Integrating Nix into these ecosystems becomes incredibly impractical
because we run into nested user namespace and mount restrictions."
I don't know enough details to really judge but it seems to me like you are
trying to workaround a mess in userspace with kernel changes.
Anyway I'm pretty sure Christian will have more educated answer than me but
I just wanted to express my skepticism about this approach and that perhaps
you wait for feedback from him before spending more time on these patches.
Honza
--
Jan Kara <[email protected]>
SUSE Labs, CR
