Hi, I am another Nix developer, and have participated in some LKML discussions in the (recent and distant) past, and thought I should weigh in here too.
On Mon, Jun 22, 2026, at 1:15 PM, Farid Zakaria wrote: > On Mon, Jun 22, 2026 at 3:40 AM Jan Kara <[email protected]> wrote: > > 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. > > > > 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. > > 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. Yes, the idea of making "relocatable software" is not a new one, and indeed it is why `$ORIGIN` is supported in the RPATH etc. in the first place. Most of the programming model for writing relocatable software is fixed at this point. For example, /proc/self/exe made it much easier to look up arbitrary stuff relevant to the current executable. It is just some initial entry point stuff (the ELF interpreter, and shebangs) which is a glaring exception. Those should support `$ORIGIN` too. There is no good technical justification (that I can think of) for some but not all of these supporting `$ORIGIN` --- either it makes sense everywhere, or it makes sense nowhere. (I suspect the only reason it didn't happen was pure inertia/Conway's law --- easier for whoever was excited about `$ORIGIN` to change the glibc loader than the kernel.) > 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. Yes, exactly. Traditionally people thought "eh `/lib/ld-linux.so.*` doesn't change too much", and decided relocatable software that nonetheless hard-coded that absolute path to an unknown system-provided ELF interpreter was good enough. (Or if they weren't good enough, they went with static linking, but that imposes other costs.) Now there do exist purely-user-space work-arounds, like https://github.com/Mic92/wrap-buddy, but they are quite complex, and involve various patching trickery that is likely to scare a lot of security analysis tools. A kernel-based solution that allows clean declarative expression of intent with `$ORIGIN` is much more elegant. > > 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 think it is good to see what Conda does as documented in <https://docs.conda.io/projects/conda-build/en/stable/resources/make-relocatable.html> and consider why relying on namespaces vs good old-fashioned relocatable isn't good enough for them either. (I don't doubt that Conda would find this approach more robust than their sedding tricks, and prefer to use it where possible.) The short answer is while all of us in the build system space love sandboxing during the build, we don't want that to lead to *requiring* run time sandboxing of the built artifacts. For example, we can certainly arrange sandboxing so `/lib/ld-linux.so.*` is the one that some executable expects now, but every time that executable is run, it *must* be run in a root filesystem where `/lib/ld-linux.so.*` is the loader it expects. If you have multiple programs that (for whatever reasons) expect multiple different loaders, all spawning one another, it would potentially incur quite the development cost to ensure that they all do the proper unsharing to make everything work. Relocatability recognizes that whether or not namespaces exist, in an "open world" scenario where we don't know how the software we are writing will be combined with other software for deployment downstream in different ways, it is easiest to adopt an idiom where different things can be placed at different absolute paths, at the user's discretion, and so conflicts are always avoidable. > > 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 Waiting makes sense, I am curious too what he will have to say.
