On Mon, Jun 22, 2026 at 3:40 AM Jan Kara <[email protected]> wrote: > > 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
Thank you for taking the time to look at my patch. I'm new to contributing to Linux mailing list so receiving feedback and responses is welcoming :) Having put forward the patch, I'm clearly biased toward thinking this support should exist in the kernel. If I had to think to strengthen my argument would be that the kernel should not be imposing how the interpreter is found on userland. Finding the interpreter relative to the binary would be useful for package deployment scenarios similar to app-bundles beyond systems like Nix -- which is the originating reason why $ORIGIN exists in the dynamic linker. To me, the gap is that prior to systems like Nix, the idea of wanting your dynamic linker to be part of your app bundle was not necessary but Nix models the dependency chain down to the loader. Such functionality would be even more correct for these other bundled solutions as well, making them portable across userspace glibc versions for instance. I see Jori Koolstra mentioned that Sashiko found feedback on the implementation. Is it worthwhile to amend the patch now or should I wait to hear back on whether such a contribution would be accepted? Jori: I'm not 100% clear on your question but the LLM assisted with some code generation and brainstorming.
