| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
GStreamer searches for plugins relative to its binary's location.
However, since https://gitlab.freedesktop.org/gstreamer/gstreamer/-/commit/bd97973ce0f2c5495bcda5cccd4f7ef7dcb7febc, it uses its *real* binary location, breaking the FHS.
Fixes #311004 (tested on Heroic and Lutris too).
|
|
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.
|
|
|
|
|
|
Fixes issues using bubblewrap'd fhsenvs in scenarios where i686 is not
supported (such as Rosetta 2 emulation in a Linux VM on Apple Silicon).
|
|
|
|
pkgs/build-support/build-fhsenv-bubblewrap/default.nix
|
|
* added more comments.
* symlink fhsenv etc entries when necessary.
|
|
|
|
`multiPaths` is defined via invalid operation on `null` value for
non-multilib environments. Noticed on `notesnook` evan failure as:
nix-repl> notesnook.fhsenv.multiPaths
253| passthru = {
254| inherit args baseTargetPaths targetPaths baseMultiPaths multiPaths ldconfig;
| ^
255| };
error: attempt to call something which is not a function but null
The change makes `multiPaths` a private variable.
|
|
|
|
|
|
This fixes use cases like launching Lutris/Heroic from Steam.
|
|
Works around steam's misbehavior: https://github.com/ValveSoftware/steam-for-linux/issues/9121
|
|
Closes #247065
|
|
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.
|
|
See https://github.com/NixOS/nixpkgs/issues/262775
|
|
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: allow being passed 'pname'
|
|
`buildFHSEnvBubblewrap { pname = ...; }` currently results in eval error
because args.name doesn't exist then. Fix it by only using args.name if
it exists.
|
|
It's useful to be able to introspect all packages which are available
in the fhsenv. I've renamed basePkgs and baseMultiPkgs to be
consistent with the naming scheme used for the bits that were
previously public — names ending in "Pkgs" are for functions, and
names ending in "Paths" are the results of those functions.
|
|
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.
|
|
Before the change the following command did not work:
$ nix develop -i --impure --expr 'with import <nixpkgs> { system = "i686-linux"; }; (buildFHSUserEnv { name = "t"; targetPkgs = ps: with ps; [ libmpc stdenv.cc ]; }).env'
$ ld -lmpc -o a
ld: cannot find -lmpc: No such file or directory
It is expected to work as `NIX_LDFLAGS` does contain valid values:
$ echo $NIX_LDFLAGS
-L/usr/lib -L/usr/lib32
Note that for `gcc` it does work:
$ printf "int main(){}" | gcc -x c - -lmpc -o a
It happens because `HOST` role is enabled for `cc`:
$ echo $NIX_CC_WRAPPER_TARGET_HOST_i686_unknown_linux_gnu
1
But not for `BINTOOLS`:
$ echo $NIX_BINTOOLS_WRAPPER_TARGET_HOST_i686_unknown_linux_gnu
<empty>
The change adds BINTOOLS role and fixes linking:
$ nix develop -i --impure --expr 'with import ~/nm { system = "i686-linux"; }; (buildFHSUserEnv { name = "t"; targetPkgs = ps: with ps; [ libmpc stdenv.cc ]; }).env'
$ printf "int main(){}" | gcc -x c - -lmpc -o a
$ ld -lmpc -o a
ld: warning: cannot find entry symbol _start; not setting start address
|
|
Most FHSEnv-wrapped packages in Nixpkgs wrap a x86_64-linux binary; making
multiArch unnecessary bloat closure size. Saves about 1G in anki-bin.
This makes multiArch FHSEnvs the exception rather than the rule.
|
|
The intention is to allow the user control over whether 32bit deps are supposed
to be included in the fhsenv
|
|
|
|
This reverts commit 840f2e0ac566862d93aff6721351fc09977c1f54, reversing
changes made to d3ed0402e50852342ec06edfe4bd23f597d5ae2a.
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.
|
|
buildFHSEnvBubblewrap: escape runScript path
|
|
Fixes https://github.com/NixOS/nixpkgs/issues/230651
Co-authored-by: Weijia Wang <9713184+wegank@users.noreply.github.com>
|
|
|
|
|
|
|
