doc: rewrite the multi-user documentation to actually talk about security

It's in the security section, and it was totally outdated anyway.

I took the opportunity to write down the stuff we already believed.

Change-Id: I73e62ae85a82dad13ef846e31f377c3efce13cb0

src/libfetchers/fetch-settings.hh

@@ -87,7 +87,17 @@ struct FetchSettings : public Config
         {}, true, Xp::Flakes};
 
     Setting<bool> acceptFlakeConfig{this, false, "accept-flake-config",
-        "Whether to accept nix configuration from a flake without prompting.",
+        R"(
+          Whether to accept Lix configuration from the `nixConfig` attribute of
+          a flake without prompting. This is almost always a very bad idea.
+
+          Setting this setting as a trusted user allows Nix flakes to gain root
+          access on your machine if they set one of the several
+          trusted-user-only settings that execute commands as root.
+
+          See [multi-user installations](@docroot@/installation/multi-user.md)
+          for more details on the Lix security model.
+        )",
         {}, true, Xp::Flakes};
 
     Setting<std::string> commitLockFileSummary{

src/libstore/derivations.hh

@@ -208,7 +208,7 @@ struct DerivationType {
     /**
      * Impure derivation type
      *
-     * This is similar at buil-time to the content addressed, not standboxed, not fixed
+     * This is similar at build-time to the content addressed, not sandboxed, not fixed
      * type, but has some restrictions on its usage.
      */
     struct Impure {

src/libstore/globals.hh

@@ -331,7 +331,7 @@ public:
           performed by the Lix account since that would allow users to
           arbitrarily modify the Nix store and database by supplying specially
           crafted builders; and they cannot be performed by the calling user
-          since that would allow him/her to influence the build result.
+          since that would allow them to influence the build result.
 
           Therefore, if this option is non-empty and specifies a valid group,
           builds will be performed under the user accounts that are a member
@@ -352,10 +352,17 @@ public:
 
           If the build users group is empty, builds will be performed under
           the uid of the Lix process (that is, the uid of the caller if
-          `NIX_REMOTE` is empty, the uid under which the Nix daemon runs if
-          `NIX_REMOTE` is `daemon`). Obviously, this should not be used
+          both `NIX_REMOTE` is either empty or `auto` and the Nix store is
+          owned by that user, or, alternatively, the uid under which the Nix
+          daemon runs if `NIX_REMOTE` is `daemon` or if it is `auto` and the
+          store is not owned by the caller). Obviously, this should not be used
           with a nix daemon accessible to untrusted clients.
 
+          For the avoidance of doubt, explicitly setting this to *empty* with a
+          Lix daemon running as root means that builds will be executed as root
+          with respect to the rest of the system.
+          We intend to fix this: https://git.lix.systems/lix-project/lix/issues/242
+
           Defaults to `nixbld` when running as root, *empty* otherwise.
         )",
         {}, false};

src/nix/flake.md

@@ -394,15 +394,17 @@ The following attributes are supported in `flake.nix`:
   value (e.g. `packages.x86_64-linux` must be an attribute set of
   derivations built for the `x86_64-linux` platform).
 
-* `nixConfig`: a set of `nix.conf` options to be set when evaluating any
-  part of a flake. In the interests of security, only a small set of
-  set of options is allowed to be set without confirmation so long as [`accept-flake-config`](@docroot@/command-ref/conf-file.md#conf-accept-flake-config) is not enabled in the global configuration:
+* `nixConfig`: a set of `nix.conf` options to be set when evaluating any part of a flake.
+  This attribute is only considered if the flake is at top-level (i.e. if it is passed directly to `nix build`, `nix run`, etc, rather than as an input of another flake).
+  In the interests of security, only a small set of set of options is allowed to be set without confirmation so long as [`accept-flake-config`](@docroot@/command-ref/conf-file.md#conf-accept-flake-config) is not enabled in the global configuration:
    - [`bash-prompt`](@docroot@/command-ref/conf-file.md#conf-bash-prompt)
    - [`bash-prompt-prefix`](@docroot@/command-ref/conf-file.md#conf-bash-prompt-prefix)
    - [`bash-prompt-suffix`](@docroot@/command-ref/conf-file.md#conf-bash-prompt-suffix)
    - [`flake-registry`](@docroot@/command-ref/conf-file.md#conf-flake-registry)
    - [`commit-lockfile-summary`](@docroot@/command-ref/conf-file.md#conf-commit-lockfile-summary)
 
+  For the avoidance of doubt, setting `accept-flake-config` in `nix.conf` or passing `--accept-flake-config` *allows root access to your machine* if you are running as a trusted user and don't read `nixConfig` in every flake you build.
+
 ## Flake inputs
 
 The attribute `inputs` specifies the dependencies of a flake, as an