Change:
}) ./fix-x64-abi.patch <ins> /* https://github.com/NixOS/nixpkgs/pull/137601 */ ./nix-nss-open-files.patch </ins> ] ++ lib.optional stdenv.hostPlatform.isMusl ./fix-rpc-types-musl-conflicts.patch ++ lib.optional stdenv.buildPlatform.isDarwin ./darwin-cross-build.patch;

Discussion:
Describe the bug Certain functions in glibc look for files present in /etc such as which reads . If you are using Nix over a Linux installation, this file may not be present, and therefore it will cause errors. Nix should strive to be as reproducible and hermetic as possible. Rather than looking for the files at /etc, glibc should be patched to look for these files in the /nix/store; very similar to how Nix does LOCALARCHIVE. Right now the guidance is to use libredirect () which seems unfortunate and annoying to users. Useful links: Notify maintainers I did not see any explicit maintainers, so tagged a few from the history of the file.
Is this file not supposed to be configurable? Or do you mean there should be environment variables to redirect it?
The file in glibc is hardcoded. For instance on a Debian installation you must have . Ultimately shouldn't everything be self-contained to the /nix/store ? Seems like it's less of a problem on NixOS but on Nix on other Linux distributions it should reading from another nixpkg similar to LOCAL_ARCHIVE.
I think that adding such variables should only be done very carefully. I suspect there are some reasons for restricting some of these (say, LDLIBRARYPATH) in setuid binaries, and we might just be adding a security hole this way (a small-ish one if any, I expect, but still).
I'm not really following your logic reading files outside of the /nix/store and relying on the environment though is antithesis to the concept of Nix and it's versioning. I think this aligns close to many other similar patches such as that to clang/gcc to not read from default library paths or the locales as mentioned.
is runtime configuration data, just like or or . You don't want to rebuild the entire system just to change . Now, in practice nobody ever changes so we could get away with hard-coding it, but it would be a bit fishy. The same applies to BTW.
I don't expect people really need to change this often in practice and years old version would typically suffice, but for those reasons I understand that it may be appealing to add runtime configurability by an environment variable (and keep the same default if it's not defined).

And the potential risks I know about should be fixable by copy&paste of the usual setuid checks (like for LDLIBRARYPATH). Using setuid for nix-built executables on non-NixOS is probably not common anyway. Maybe just... the overall design of these customizations could be given some more thought.
See also , which proposes adding an environment variable for the NSS search path, and which proposes a generic environment variable.
I guess rather than hardcode, I am advocating for something similar to make an environment variable override. It's just a bummer than out-of-the-box on Debian, Nix can cause failures since glibc does not find these files. Maybe a fallback to an entry in the /nix/store ? I'll read the pivot link thanks.
Uh, I wonder what Debian's glibc does then. Any package with a binary using these syscalls should declare a dependency on ?
That's my understanding; and-or it's brought in eventually and the problem stabilizes. (That non-determinism seems perfect for Nix to solve)
We might also make depend on on Debian :trollface: (say, for the short term)
It might be worth noting that go in nixpkgs actually does hardcode this, since . Maybe that has been reverted at some point, but when I looked into this () it was still the case.
Interesting; well that's only for golang built binaries in Nixpkgs. Should I put time on this for a patch or is there a broader discussion here that is more well suited for an RFC?
No. just make a PR.
PR incoming today.
Wow; I spent time trying to dig through the glibc code -- intense. The getproto code is very macro heavy
The glibc code quality is quite bad. Mainly because of one former long-term maintainer. helps to expand/understand macros.
:( I really wanted to patch it. Maybe I'll give it another shot to walk the macros later ...
If it's runtime configuration data, oughtn't we include it in the sandbox?