dockerTools: Keep fakechroot disabled by default

Avoid risk of breaking existing images by making it opt-in.
This commit is contained in:
Robert Hensing 2021-12-04 13:17:56 +00:00
parent 0e9bc9ffd1
commit ddda5f28e1
5 changed files with 6 additions and 16 deletions

View file

@ -149,13 +149,13 @@ Create a Docker image with many of the store paths being on their own layer to i
`fakeRootCommands` _optional_
: Shell commands to run while creating the archive for the final layer in a fakeroot + fakechroot environment. Unlike `extraCommands`, you can run `chown` to change the owners of the files in the archive, changing fakeroot's state instead of the real filesystem. The latter would require privileges that the build user does not have. Static binaries do not interact with the fakeroot environment. By default all files in the archive will be owned by root.
: Shell commands to run while creating the archive for the final layer in a fakeroot environment. Unlike `extraCommands`, you can run `chown` to change the owners of the files in the archive, changing fakeroot's state instead of the real filesystem. The latter would require privileges that the build user does not have. Static binaries do not interact with the fakeroot environment. By default all files in the archive will be owned by root.
`enableFakechroot` _optional_
: Whether to run in `fakeRootCommands` in `fakechroot`, making programs behave as though `/` is the root of the image being created, while files in the Nix store are available as usual. This allows most scripts that perform installation in `/` to work as expected. Considering that `fakechroot` is implemented via the same mechanism as `fakeroot`, it is not guaranteed to work and will not work for static binaries.
: Whether to run in `fakeRootCommands` in `fakechroot`, making programs behave as though `/` is the root of the image being created, while files in the Nix store are available as usual. This allows scripts that perform installation in `/` to work as expected. Considering that `fakechroot` is implemented via the same mechanism as `fakeroot`, the same caveats apply.
*Default:* `true` when built on Linux, `false` otherwise
*Default:* `false`
### Behavior of `contents` in the final image {#dockerTools-buildLayeredImage-arg-contents}

View file

@ -57,14 +57,6 @@
new versions will release.
</para>
</listitem>
<listitem>
<para>
<literal>pkgs.dockerTools.buildLayeredImage</literal>/<literal>streamLayeredImage</literal>
enable <literal>enableFakechroot</literal> by default on
Linux. This might be unexpected and can be set to
<literal>false</literal> if image generation fails.
</para>
</listitem>
</itemizedlist>
</section>
<section xml:id="sec-release-22.05-notable-changes">

View file

@ -27,8 +27,4 @@ In addition to numerous new and upgraded packages, this release has the followin
org-contrib, refer to the ones in `pkgs.emacsPackages.elpaPackages` and
`pkgs.emacsPackages.nongnuPackages` where the new versions will release.
* `pkgs.dockerTools.buildLayeredImage`/`streamLayeredImage` enable
`enableFakechroot` by default on Linux.
This might be unexpected and can be set to `false` if image generation fails.
## Other Notable Changes {#sec-release-22.05-notable-changes}

View file

@ -818,7 +818,8 @@ rec {
fakeRootCommands ? ""
, # Whether to run fakeRootCommands in fakechroot as well, so that they
# appear to run inside the image, but have access to the normal Nix store.
enableFakechroot ? pkgs.stdenv.buildPlatform.isLinux
# Perhaps this could be enabled on by default on pkgs.stdenv.buildPlatform.isLinux
enableFakechroot ? false
, # We pick 100 to ensure there is plenty of room for extension. I
# believe the actual maximum is 128.
maxLayers ? 100

View file

@ -566,6 +566,7 @@ rec {
name = "image-via-fake-chroot";
tag = "latest";
config.Cmd = [ "hello" ];
enableFakechroot = true;
# Crucially, instead of a relative path, this creates /bin, which is
# intercepted by fakechroot.
# This functionality is not available on darwin as of 2021.