Add /bin/bash to avoid unnecessary pain

I think that would be much better than making NixOS less pure by default. Although my understanding may be too limited, but wouldn’t this be possible with just an additional option to one of the environment modules?

Of course, people should be warned of the risks of doing that, but I guess it may be a good springboard. Once people are settled, they could disable that option.

Color me impressed, I wouldn’t expect that, but that’s good to hear. Maybe it’s because I started using Nix on macOS before using NixOS (which breaks more frequently).

1 Like

Related rejected PR: https://github.com/NixOS/nixpkgs/pull/78798
Related merged PR: https://github.com/NixOS/nixpkgs/pull/69057

EDIT: last PR was just reverted by Eelco

1 Like

As https://github.com/NixOS/nixpkgs/pull/69057 is merged, we have 3 almost identical code blocks for
system.activationScripts.binsh
system.activationScripts.usrbinenv
system.activationScripts.ld-linux
and 2 options
environment.usrbinenv
environment.ld-linux
That code duplication is already enough reason to refactor and convert them into a generic option accepting list of symlinks.
And an user could add /bin/bash or /lib or whatever to that list without making PRs

4 Likes

volth’s suggestion would simplify the documentation of these exceptions, wouldn’t it? That would be a very big argument in its favour, IMO.

@volth looks like that just got reverted :confused:.

Would love to see that as a flake or NUR, along with @matthewbauer’s LSB pull request.

When I started with NixOS I saw buildFHSUserEnv as a viable solution, but it (and nix-shell) are not production-ready, at least for software that I use. I’ve encountered a number of segmentation faults that due not occur outside of that environment, particularly when opening large files and processes with high memory / swap utilization. I don’t mean to criticize—I think these are fantastically useful tools—they just aren’t as tested and robust as a vanilla FHS, particularly for scientific/high-performance applications.

One could argue that we should instead “nixify” the world, and indeed many of us have contributed packages needed for our workflows to nixpkgs. But it’s too onerous to require users to make a nix package for everything and we’ll never have 100% coverage.

As such, the only practical solution I see is to capitulate to (de facto) Linux standards, or at least allow users to opt into this without too much effort. Allowing third party binaries to “just work” would be a huge productivity boon, and does not contradict the benefits of Nix.

zimbatm had a nice related post here: https://github.com/NixOS/nixpkgs/pull/78798

1 Like

But it could negatively impact Nix in two ways: 1. there is less incentive to package software properly, 2. there will be PRs from people with impure systems, which are possibly incorrect, leading to a higher maintenance burden.

I think there is a parallel to draw here with SELinux in Red Hat distributions. A lot of third-party guides recommend users to disable SELinux because it makes it simpler to use third-party software. Fedora/Red Hat prefer people to keep it enabled, to receive one of the benefits of their distributions (strong security) and to catch policy violations and refine the SELinux policies. It’s a discussion that cannot really be resolved, because both sides are right: people need to get things done; but others need to guard that what makes a system unique should not be thrown out with the bathwater.

In the aforementioned PR, Eelco suggested making a NUR repository or flake. Wouldn’t that be a good solution? People could introduce the impurity when needed, but it would not be endorsed by NixOS.

5 Likes

Just for reference — you mean this faults do not occur on NixOS if you properly patchelf? Because Nixpkgs is not perfect in more than just not setting FHS envs perfectly, maybe Nixpkgs version of some library is compiled with the flags the program doesn’t like or something like that.

1 Like

What a great example. I’ve seen countless tutorials online that start with “First disable SELinux…”. I would hate to see countless NixOS guides starting with “First disable purity…”

6 Likes

Why hate?
If it is the way to boost the number of NixOS guides from less than a dozen to “countless”, it is worth to try. And then fix the purity.

2 Likes

Once something is supported it is very hard to revert.

I find some of the “pain” in Nix packaging to be very helpful to projects themselves as it helps find impurities in them. Most projects welcome the feedback. I also find a common correlation between project maturity and ease of Nix integration.

Here is a typical interaction with a project:

2 Likes

I was thinking of https://github.com/NixOS/nixpkgs/issues/75590 for example. Using np.memap in a nix-shell or buildFHSUserEnv triggers a Bus error, but works fine in a python interpreter (using the same nixpkgs for all).

3 Likes

The custom buildFHSUserEnv chroot script should probably be replaced with something that’s supported by the industry. There are plenty of options out there like firejail that would do a better job and have been battle-tested.

4 Likes

I agree with @danieldk that there a bigger obstacles than not having /bin/bash. If a package is generated by a derivation patchShebangs already solves the problem. For binary packages that can not be packaged in a conventional nix fashion we use buildFHSUserEnv. Can someone maybe give an example, which does not fall in the two categories mentioned above, where the lack of /bin/bash is a problem (or at least a big annoyance)?

I would argue that what’s exposed in / should be consistent between NixOS and the build environment, which already isn’t the case. Adding more variations only makes these kind of build issues more confusing and difficult to reproduce.

  • nixos /bin/sh and /usr/bin/env
  • builds /bin/sh and no env

A great example of the kind of issues that implicit impurities can introduce https://github.com/NixOS/nixpkgs/pull/38636#issuecomment-380414258.

4 Likes

There’s certainly an argument to be made that issues/PRs replacing shebangs or asking people not to use /bin/bash are causing somewhat of an effect outside of NixOS and perhaps it’s up to this community to try and alleviate that, as I fear that it might give NixOS some unpopularity.

1 Like

I’m currently on day 3 of trying to figure out what is wrong with my build. It clearly has to do with the shebang thing, but in spite of patchShebang’ing all over the place, I still get “bad interpreter”.

Somewhere in the list of scripts both static and generated something is not good.
I don’t think one can anticipate all the possible uses and don’t see why one should.

/bin/bash is the most minimal expectation.

/bin/bash is still impure.

if you really want a “quick and dirty”, you can always do:

nix-shell -p steam-run --run "steam-run <program>"
1 Like

I don’t want quick and dirty. I just want a minimum of unsolvable puzzles.

Like:
[ 85%] Generating asn1.cert.pem, coordinates.bin, ec_cert_with_ext.pem, ec_cert_crl_distribution.pem, intermediate.crl.der, intermediate.cert.pem, intermediate.ec.cert.pem, intermediate2.cert.pem, leaf.key.pem, leaf.cert.pem, leaf.ec.cert.pem, leaf.public.key.pem, leaf_modulus.hex, leaf2.cert.pem, root.crl.der, root.cert.pem, root.ec.cert.pem, root.ec.key.pem, root.ec.public.key.pem, root2.cert.pem, self_signed.cert.der, test_ec_signature, test_rsa_signature, time.txt
cd /nix/store/78rvpsgfp9g92sl30620ywr4239mwwpa-openenclave-sdk/tests/crypto/data && /nix/store/k8p54jg8ipvnfz435mayf5bnqhw4qqap-bash-4.4-p23/bin/bash -c /nix/store/myjxqm5qbx9gsq6spvcy73hac5rwj89w-source/tests/crypto/data/make-test-certs\ /nix/store/myjxqm5qbx9gsq6spvcy73hac5rwj89w-source/tests/crypto/data\ /nix/store/78rvpsgfp9g92sl30620ywr4239mwwpa-openenclave-sdk/tests/crypto/data\ --bash
/nix/store/k8p54jg8ipvnfz435mayf5bnqhw4qqap-bash-4.4-p23/bin/bash: /nix/store/myjxqm5qbx9gsq6spvcy73hac5rwj89w-source/tests/crypto/data/make-test-certs: /nix/store/6h0xx5d8wwl8zf7g4x2sjl0q4hr3nnb4-bash-interactive-4.4-p23/bin/bash: bad interpreter: No such file or directory
make[2]: *** [tests/crypto/data/CMakeFiles/crypto_test_data.dir/build.make:103: tests/crypto/data/asn1.cert.pem] Error 126
make[2]: Leaving directory ‘/nix/store/78rvpsgfp9g92sl30620ywr4239mwwpa-openenclave-sdk’
make[1]: *** [CMakeFiles/Makefile2:19204: tests/crypto/data/CMakeFiles/crypto_test_data.dir/all] Error 2
make[1]: Leaving directory ‘/nix/store/78rvpsgfp9g92sl30620ywr4239mwwpa-openenclave-sdk’

This expression works fine in nix-shell --pure but something is wrong in nix-build…

I have more details in the other post (sudden EOF)…
I’ve tried adding patchShebang everywhere but no luck.

Development:

I removed the shebang altogether and it built. Apparently patchShebangs gets confused?

--pure makes the environment pure but does not chroot your shell (does not run it in a sandbox without file system access). If the project tries to use impure paths on the file system instead of relying on PATH, it will be able to access them. It is a compromise between fully hermetic build environment (like the one inside nix-build) and fully impure one with access to the environment variables set by your system.

1 Like