From 3009b12817c15e439609aaa794815de40a27564b Mon Sep 17 00:00:00 2001 From: Atemu Date: Sun, 21 May 2023 13:06:52 +0200 Subject: [PATCH] doc:fhs-envs: reword --- doc/builders/special/fhs-environments.section.md | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/doc/builders/special/fhs-environments.section.md b/doc/builders/special/fhs-environments.section.md index 91d4060cdeb1..5a248e4ead92 100644 --- a/doc/builders/special/fhs-environments.section.md +++ b/doc/builders/special/fhs-environments.section.md @@ -1,9 +1,12 @@ # buildFHSEnv {#sec-fhs-environments} -`buildFHSEnv` provides a way to build and run FHS-compatible lightweight sandboxes. It creates an isolated root with bound `/nix/store`, so its footprint in terms of disk space needed is quite small. This allows one to run software which is hard or unfeasible to patch for NixOS -- 3rd-party source trees with FHS assumptions, games distributed as tarballs, software with integrity checking and/or external self-updated binaries. It uses Linux namespaces feature to create temporary lightweight environments which are destroyed after all child processes exit, without root user rights requirement. Accepted arguments are: +`buildFHSEnv` provides a way to build and run FHS-compatible lightweight sandboxes. It creates an isolated root filesystem with the host's `/nix/store`, so its footprint in terms of disk space is quite small. This allows you to run software which is hard or unfeasible to patch for NixOS; 3rd-party source trees with FHS assumptions, games distributed as tarballs, software with integrity checking and/or external self-updated binaries for instance. +It uses Linux' namespaces feature to create temporary lightweight environments which are destroyed after all child processes exit, without requiring elevated privileges. It works similar to containerisation technology such as Docker or FlatPak but provides no security-relevant separation from the host system. + +Accepted arguments are: - `name` - Environment name. + The name of the environment and the wrapper executable. - `targetPkgs` Packages to be installed for the main host's architecture (i.e. x86_64 on x86_64 installations). Along with libraries binaries are also installed. - `multiPkgs` @@ -22,7 +25,7 @@ - `profile` Optional script for `/etc/profile` within the sandbox. -One can create a simple environment using a `shell.nix` like that: +You can create a simple environment using a `shell.nix` like this: ```nix { pkgs ? import {} }: @@ -45,6 +48,7 @@ One can create a simple environment using a `shell.nix` like that: }).env ``` -Running `nix-shell` would then drop you into a shell with these libraries and binaries available. You can use this to run closed-source applications which expect FHS structure without hassles: simply change `runScript` to the application path, e.g. `./bin/start.sh` -- relative paths are supported. +Running `nix-shell` on it would drop you into a shell inside an FHS env where those libraries and binaries are available in FHS-compliant paths. Applications that expect an FHS structure (i.e. proprietary binaries) can run inside this environment without modification. +You can build a wrapper by running your binary in `runScript`, e.g. `./bin/start.sh`. Relative paths work as expected. Additionally, the FHS builder links all relocated gsettings-schemas (the glib setup-hook moves them to `share/gsettings-schemas/${name}/glib-2.0/schemas`) to their standard FHS location. This means you don't need to wrap binaries with `wrapGAppsHook`.