Slim with --include-exe doesn't preserve the executable

[duncanmmacleod]

Expected Behavior

--include-exe=mkdir results in a slim image that includes mkdir without needing to specify any other --include-* options or --exec.

I'm sorry if this is 'user error' because I didn't read the manual properly.

---

Actual Behavior

--include-exe=mkdir seems to have no impact at all and creates an image that does not include mkdir.

Slim container contents (from docker export)

.dockerenv
bin
dev/
dev/console
dev/pts/
dev/shm/
etc/
etc/host.conf
etc/hostname
etc/hosts
etc/mtab
etc/nsswitch.conf
etc/passwd
etc/pki/
etc/pki/ca-trust/
etc/pki/ca-trust/extracted/
etc/pki/ca-trust/extracted/openssl/
etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt
etc/pki/ca-trust/extracted/pem/
etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
etc/pki/java/
etc/pki/java/cacerts
etc/pki/tls/
etc/pki/tls/cert.pem
etc/pki/tls/certs/
etc/pki/tls/certs/ca-bundle.crt
etc/pki/tls/certs/ca-bundle.trust.crt
etc/resolv.conf
etc/ssl/
etc/ssl/cert.pem
etc/ssl/certs/
etc/ssl/certs/ca-bundle.crt
lib
lib64
proc/
run/
sys/
tmp/
usr/
usr/bin/
usr/bin/bash
usr/bin/ld.so
usr/bin/sh
usr/lib/
usr/lib/.build-id/
usr/lib/.build-id/46/
usr/lib/.build-id/46/d8c77d92436bbcafcf16f6737ab9d6a16f3a38
usr/lib/.build-id/7a/
usr/lib/.build-id/7a/cbb41bf6f1b7d977f1b44675bf3ed213776835
usr/lib64/
usr/lib64/ld-linux-x86-64.so.2
usr/lib64/libc.so.6
usr/lib64/libnss_dns.so.2
usr/lib64/libnss_files.so.2
usr/lib64/libresolv.so.2
usr/lib64/libtinfo.so.6.2

---

Steps to Reproduce the Problem

The following bash script should reproduce things (based on Debian under WSL2):

#!/bin/bash
cat > Dockerfile << DOCKERFILE
FROM rockylinux:9
RUN dnf -qy install /usr/bin/mkdir
DOCKERFILE
docker run --rm \
  -v $(pwd):/code \
  -v /var/run/docker.sock:/var/run/docker.sock dslim/slim:1.40.11 \
  --crt-api-version 1.25 \
  build \
  --dockerfile Dockerfile \
  --dockerfile-context /code \
  --http-probe-off \
  --include-exe=mkdir \
  --tag test:slim

docker run --rm -it test:slim mkdir -pv /tmp/tmp/tmp

---

Specifications

• Version: 1.40.11
• Platform: Linux WR189341E94201 5.15.153.1-microsoft-standard-WSL2 #1 SMP Fri Mar 29 23:14:13 UTC 2024 x86_64 GNU/Linux (Docker version 27.2.0, build 3ab4256)

[kcq]

Maybe this could be Rockylinux-related... Still need to repro (hope to do it soon). In the meantime, you can use this test command to keep mkdir in ubuntu:22.04: mint slim --http-probe-off --include-shell --include-exe=mkdir ubuntu:22.04 and then you can verify that it's there with docker run -it ubuntu.slim mkdir -pv /tmp/tmp/tmp or you can docker run -it --rm ubuntu.slim bash and once inside you can use mkdir. Note that you probably want the --include-shell flag too. It's also good to use the latest release

[kcq]

It does appear to be rockylinux related :-) investigating...

[duncanmmacleod]

It's also good to use the latest release

I thought I was, looking here. But I see that mint is a subtly different project. Can you explain (or point me at the explanation of) the relationship between slimtoolkit/slim and mintoolkit/mint?

[duncanmmacleod]

I confirm that in a debian:stable image, I do not see the same behaviour.

[duncanmmacleod]

Note that if I do patch the bash script in the description to use mintoolkit/mint:1.41.7 I get the following error:

cmd=slim info=build.error status='standard.image.build.error' value='missing output stream'

This does not happen with 1.41.6. Happy to repost that as a separate issue over on the mint project if appropriate.

[duncanmmacleod]

It does appear to be rockylinux related :-) investigating...

In case it helps I have reproduced the problem on all of the following

• rockylinux:8
• rockylinux:9
• almalinux:8
• almalinux:9
• quay.io/centos/centos:stream9

so this seems to span all RHEL derivatives. I have not been able to reproduce on alpine:latest, archlinux:latest, or debian:stable.

[kcq]

thanks a lot for the extra info @duncanmmacleod !

[kcq]

Turns out the problem there is that on Rocky mkdir is not a binary executable. it's a wrapper shell script that points to an actual binary (#!/usr/bin/coreutils --coreutils-prog-shebang=mkdir).

A quick workaround there is to use these flags: --include-path=/usr/bin/mkdir, --include-bin=/usr/bin/coreutils

--include-shell tries to include ls (in addition to a few other shell commands), which is also a wrapper for /usr/bin/coreutils, so it's not kept for the same reason.

Hope to have an enhancement for this in the next version where it'll handle the wrapper scripts when binary files are expected.