`makeWrapper` is often used in these with `source "${makeWrapper}/nix-support/setup-hook"`
which causes `error: makeWrapper/makeShellWrapper must be in nativeBuildInputs` on cross.
Prior to this commit it was not possible to modify e.g. the list of ignored directories at all, however given that `buildFHSEnvBubblewrap` effectively uses a sandboxing tool (*bwrap*) I feel like this is a missed opportunity.
The code in nixpkgs already covers all the knobs that are required to get *Nix* itself to run inside bubblewrap, so why not allow users to make that additional modification?
While additional `ro_mounts` and such can be *added* to the bubblewrap invocation, the already mounted directories cannot be removed, and even if shadowed by e.g. a tmpfs mount, this would still allow something inside the sandbox to potentially unmount the tmpfs and access the data.
So what this change does is moving the snippet where custom code can be injected down by four lines so that users can actually modify those variables e.g. using `ignored+=( /home /srv /mnt /boot )`.
The only cases in which this would break is:
- someone using those variable names in `extraPreBwrapCmds` already and relying on them being overwritten; I would consider that chance slim, and the fix would be easy enough
- someone using a construct like `false && \` to disable the `ignored` initialisation and effectively working around this limitation; again the chances are slim (even though I know I'd be affected), and the fix would be easy enough (as this change makes the workaround needless anyway so it's an improvement)
Signed-off-by: benaryorg <binary@benary.org>
The $DISPLAY variable has a format of [host]:num[.screen]. Previously,
the number would only be extracted properly if it had the form :num.
Allow all forms but correctly discard the unused parts.
when bubblewraps tries to link all the required files in etc from the
host to the fhs environment, it will re-create the /etc directory.
It will do so with `0700` permissions. This causes permissions issues
with non-root programs when they need to access configuration in the
environment /etc.
By mounting /etc as a tmpfs early, bwrap will make the directory `0755`
as expected.
It's useful to have access to these attributes from packages built with
buildFHSEnvBubblewrap, and it reduces the difference between FHS and
non-FHS packages.
'name' is already handled by runCommandLocal.
`buildFHSEnvBubblewrap { pname = ...; }` currently results in eval error
because args.name doesn't exist then. Fix it by only using args.name if
it exists.
The implicit contract of buildFHSUserEnv was that it allows to run
software built for a typical GNU/Linux distribution (not NixOS) without
patching it (patchelf, autoPatchelfHook, etc.). Note that this does not
inherently imply running untrusted programs.
buildFHSUserEnv was implemented by using chroot and assembling a
standard-compliant FHS environment in the new root. As expected, this
did not provide any kind of isolation between the system and the
programs.
However, when it was later reimplemented using bubblewrap
(PR #225748), which *is* a security tool, several isolation features
involving detaches Linux namespaces were turned on by default.
This decision has introduced a number of breakages that are very
difficult to debug and trace back to this change.
For example: `unshareIPC` breaks software audio mixing in programs using
ALSA (dmix) and `unsharePID` breaks gdb,
Since:
1. the security features were enable without any clear threat model;
2. `buildFHSEnvBubblewrap` is supposed to be a drop-in replacement of
`buildFHSEnvChrootenv` (see the release notes for NixOS 23.05);
3. the change is breaking in several common cases (security does not
come for free);
4. the contract was not changed, or at least communicated in a clear
way to the users;
all security features should be turned off by default.
P.S. It would be useful to create a variant of buildFHSEnv that does
provide some isolation. This could unshare some namespaces and mount
only limited parts of the filesystem.
Note that buildFHSEnv mounts every directory in / under the new root, so
again, very little is gained by unsharing alone.
This reverts commit 840f2e0ac5, reversing
changes made to d3ed0402e5.
This breaks appimage which puts args into the runScript and we don't provide a
good way to pass thru additional args.
The actual bug was in nix-alien which should escape paths; providing a valid
runScript is the responsibility of the caller.
