If bash is executed within an environment where PATH is not set, it uses
the DEFAULT_PATH_VALUE compiled into bash to set PATH. In nixpkgs we set
this to /no-such-path by default. This makes sense in a nixpkgs/NixOS
environment since paths like /bin or /usr/bin should not be used.
However, when bash is used inside an FHS environment, this produces
results that differ from distributions which follow the FHS standard.
Before this change:
$ steam-run env -i /bin/bash -c 'echo $PATH'
/no-such-path
After this change:
$ steam-run env -i /bin/bash -c 'echo $PATH'
/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:.
It seems as if it's a problem if `/etc/resolv.conf` is a symlink to
`/run/systemd/resolve/stub-resolv.conf` which is the case when using
`systemd-resolved.service`:
bwrap: Can't bind mount /oldroot/etc/resolv.conf on /newroot/etc/resolv.conf: Unable to mount source on destination: No such file or directory
I confirmed that by following the symlink of `/etc/resolv.conf`
(pointing to `/run/systemd/resolve/stub-resolv.conf`) with `readlink -f`
the issues are all gone.
In Arch Linux, many of the certs in /etc/ssl/certs/ are symlinks to
/etc/ca-certificates/extracted/. These symlinks are broken in the FHS
env.
This commit adds ca-certificates to the list of bind mounts, which fixes
connection issues with Steam, wget, etc on Arch Linux hosts.
The NixOS pipewire module places its alsa compatiblity configuration in
/etc/alsa/conf.d/ instead of /etc/asound.conf. This commit enables
applications running in a bubblewrap fhs environment to use alsa on
systems running pipewire.
buildFHSUserEnv is meant primarily for running 3rd-party software
which is difficult to patch for NixOS. Such software is often built to
run from /opt. Currently, running such a software from FHS environment
is difficult for two reasons:
1. If the 3rd-party software is put into the Nix store via a simple
derivation (with e.g. installPhase = "dpkg-deb -x $src $out"), the
content of /opt directory of that derivation does not appear in the
FHSEnv even if the derivation is specified in targetPkgs. This is
why we change env.nix.
2. If using buildFHSUserEnvChroot and the host system has the /opt
directory, it always gets bind-mounted to the FHSEnv even if some
targetPkgs contain /opt (NB buildFHSUserEnvBubblewrap does not have
this problem). If that directory is not accessible for non-root
users (which is what docker's containerd does with /opt :-(), the
user running the FHSEnv cannot use it.
With the change in chrootenv.c, /opt is not bind-mounted to the
container, but instead created as user-modifiable symlink to
/host/opt (see the init attribute in
build-fhs-userenv/default.nix). If needed, the user can remove this
symlink and create an empty /opt directory which is under his/her
control.
Commit df4761 added a call to readlink, which fails if it is not in the
user's path when run. Updated the readlink call to pull from the
coreutils store path directly.
Preserve top-level symlinks such as /lib -> /usr/lib.
This allows nested containers such as Steam's new runtime to remount
/usr if they need to and then run unmodified binaries that reference
e.g. /lib/ld-linux-x86-64.so.2
Before, we would mount the fully resolved host directory at /lib and
thus the dynamic loader would always be the one from the host filesystem.
Jonathan Ringer