Handle relative paths in VOLUME directives

[cpuguy83]

Description

• Related to container error after upgrade to containerd.io 1.4.6-1 containerd/containerd#5547
• Related to Consider throwing a warning on not absolute mounts destination paths opencontainers/runc#3944

In runc 1.0, runc started erroring out if a mount destination was a relative path.
This was changed to be just a warning here: opencontainers/runc#3004
An issue was created to re-add the error: opencontainers/runc#3020
As part of id-mapped mounts support, this was added back here: opencontainers/runc#3717

We need to handle this case because we don't want to break old images or builds.

Reproduce

N/A

Expected behavior

N/A

docker version

N/A

docker info

N/A

Additional Info

No response

[thaJeztah]

So for docker run at least it looks like we're producing an error;

docker run -it --rm --workdir=/hello -v foovolume:world alpine
docker: Error response from daemon: invalid volume specification: 'foovolume:world': invalid mount config for type "volume": invalid mount path: 'world' mount path must be absolute.

docker run -it --rm --workdir=/hello -v foovolume:./world alpine
docker: Error response from daemon: invalid volume specification: 'foovolume:./world': invalid mount config for type "volume": invalid mount path: './world' mount path must be absolute.

For docker build with BuildKit, it looks like we're silently allowing the relative path;

docker build -t foo -<<'EOF'
FROM alpine
WORKDIR /hello
VOLUME ./world
VOLUME world2
EOF

So the image's config has the relative path:

docker image inspect --format '{{ json .Config.Volumes}}' foo
{"./world":{},"world2":{}}

Which gets fixed "somewhere" when running a container from it.

docker run --rm foo sh -c 'mount | grep world'
/dev/vda1 on /world2 type ext4 (rw,relatime,data=ordered)
/dev/vda1 on /world type ext4 (rw,relatime,data=ordered)