Should docker build . fail when Dockerfile is a symlink pointing to ../file?

[eriksjolund]

Building with buildkit does not fail when Dockerfile is a symlink pointing to ../file.
I wonder if that is expected behavior?

The context directory contains this:

context/
├── Dockerfile -> ../file
└── file

I tried it out on Fedora CoreOS 44.20260523.1.1.
Here is a demo:

root@localhost:~# useradd test
root@localhost:~# usermod -aG docker test
root@localhost:~# systemctl start docker.socket
root@localhost:~# machinectl shell --uid=test
Connected to the local host. Press ^] three times within 1s to exit session.
test@localhost:~$ vi test3.bash
test@localhost:~$ cat test3.bash
#!/bin/bash
set -o errexit
set -o nounset
command=$1
dir=$(mktemp -d)
mkdir -p $dir/context
cat <<EOF > $dir/context/file
FROM docker.io/library/alpine
EOF

(cd $dir/context && ln -s ../file Dockerfile)
$command build -q --no-cache $dir/context

test@localhost:~$ DOCKER_BUILDKIT=1 bash test3.bash docker
sha256:b3c28a994911d479bfbddad5a09eaaf31c0c96fd5498c88ab6002a3d98cf9bda
test@localhost:~$ DOCKER_BUILDKIT=0 bash test3.bash docker
DEPRECATED: The legacy builder is deprecated and will be removed in a future release.
            BuildKit is currently disabled; enable it by removing the DOCKER_BUILDKIT=0
            environment-variable.

unable to prepare context: unable to evaluate symlinks in Dockerfile path: lstat /tmp/tmp.6l2gXyhJHE/file: no such file or directory
test@localhost:~$ 

About the system

test@localhost:~$ rpm -qa | grep docker
docker-cli-29.4.2-1.fc44.aarch64
docker-buildkit-0.30.0-1.fc44.aarch64
docker-buildx-0.34.0-1.fc44.aarch64
test@localhost:~$ rpm -qa | grep moby
moby-filesystem-29.4.2-1.fc44.noarch
moby-engine-29.4.2-1.fc44.aarch64
test@localhost:~$ rpm -qa | grep containerd
containerd-2.2.3-1.fc44.aarch64
test@localhost:~$ 

Side note: Building with the legacy builder (environment DOCKER_BUILDKIT=0) fails, so the behavior are different there.

[metehankaygsz]

This is expected from BuildKit's current context-filesystem implementation, although it is different from the legacy builder's host-filesystem dereference behavior.

First, the symlink in the reproducer is broken from the host's point of view:

$tmp/context/Dockerfile -> ../file

resolves to $tmp/file, not $tmp/context/file. The existing file would be targeted by Dockerfile -> file.

BuildKit does not dereference that path directly against the host filesystem. When loading the Dockerfile, the frontend requests it with llb.FollowPaths. The fsutil resolver treats the build context as a rooted virtual filesystem, so absolute paths and .. components cannot escape the context. In this case, ../file is clamped to /file in that virtual filesystem and resolves to context/file.

That root-clamping is deliberate and covered by an upstream test: the link outside root case expects a symlink containing enough .. components to escape to resolve back inside the filesystem root. This prevents a local context from causing BuildKit to read arbitrary files outside the submitted context.

So the practical behavior is:

• Dockerfile -> file: portable and unambiguous; both builders read context/file.
• Dockerfile -> ../file: broken on the host/legacy builder, but BuildKit resolves it as context-rooted /file.
• A real Dockerfile outside the context should be selected explicitly, e.g. docker build -f ../Dockerfile ., rather than reached through a context symlink.

It may be worth documenting the legacy difference, but BuildKit succeeding here is consistent with its security model and its tested symlink-resolution semantics; it is not reading $tmp/file outside the context.

[eriksjolund]

If I understand correctly, buildkit currently resolves Dockerfile symlinks in the same way as openat2() with the RESOLVE_IN_ROOT option.

I think it would better if buildkit would resolve Dockerfile symlinks in the same way as openat2() with the RESOLVE_BENEATH option. This would be stricter than the current behavior.

The problem with the current behavior is that if someone does the following

test@localhost:~$ cat test4.bash
#!/bin/bash
set -o errexit
set -o nounset
dir=$(mktemp -d)
mkdir -p $dir/context/context

cat <<EOF > $dir/context/file
FROM docker.io/library/alpine
RUN touch /root/test1
EOF

cat <<EOF > $dir/context/context/file
FROM docker.io/library/alpine
RUN touch /root/test2
EOF

(cd $dir/context && ln -s ../context/file Dockerfile)
cat $dir/context/Dockerfile
docker build -q --no-cache $dir/context

test@localhost:~$ DOCKER_BUILDKIT=1 bash test4.bash
FROM docker.io/library/alpine
RUN touch /root/test1
sha256:6ed440991da4ddbdf10835610b362fed5a5b5cbb12adbac62368c4cd2d16ae66
test@localhost:~$ docker run --rm sha256:6ed440991da4ddbdf10835610b362fed5a5b5cbb12adbac62368c4cd2d16ae66 ls /root
test2
test@localhost:~$ 

then the file that is shown by cat $dir/context/Dockerfile is not the Dockerfile that is used when building the container image with the command docker build -q --no-cache $dir/context