As you found, it's not possible to write to the root directory of the build environment as the build user.
I don't remember exactly, but I believe this was done as part of the fix for CVE-2021-27851 [0]. Of course it can be annoying that /bin/sh cannot be added to the build environment, but specifying a particular shell is an important part of how Guix achieves the functional packaging model. Relying on /bin/sh while building *could* be done properly with some care, but since its use could indicate that the package will use /bin/sh at run-time, we choose to omit it from the build environment, although it does exist on Guix System and most systems that Guix supports. On Mon, Nov 08, 2021 at 08:19:27PM +0000, Foo Chuan Wei wrote: > * `OS.Process.system` will always use /bin/sh. This is hardcoded. I > cannot change it. If I change it, the behavior of `OS.Process.system` > would probably be wrong in the final product (the sml compiler). > > I'm not even sure if I can use `substitute*`, since the build process > relies on binary "bootfiles" where /bin/sh is hardcoded. It will be necessary to fix this issue in the SML/NJ package definition (I think you've done this in a followup patch), because Guix does not accept packages that rely on pre-built binaries — everything must be built from source code. There are some exceptions but I don't think that SML/NJ will qualify due to its obscurity compared to other language implementations. If SML/NJ cannot be built without the binary bootfiles, it probably won't be eligible for inclusion in GNU Guix. [0] The CVE ID will appear on the blog post shortly... it took several weeks to get the ID assigned and I forgot to add it to the blog post until now. https://guix.gnu.org/en/blog/2021/risk-of-local-privilege-escalation-via-guix-daemon/
