Moby: ADD of an absolute path fails with "no such file or directory" instead of "path outside context"

[ipbabble]

Right now trying to ADD a fully qualified file name (FQFN), e.g. /home/mydir/testfile will fail with the error "no such file or directory".

The failure is on purpose for security reasons. From @tianon: Imagine that I have a Dockerfile that does "ADD /etc/shadow /my/path n RUN some-command-to-upload-your-etc-shadow-to-my-server".

However at the least the message is wrong and should be something like "forbidden path outside the context". Consider that the client might be remote from the docker daemon.

However if you have common files (tar, configuration, html etc.) that you may wish to include in multiple images, then you need to duplicate these files into each build directory. One could image having a shared file system with lots of common files that are required for different classes of images or for all images (maybe some legal/copywrite document).

How can we maintain the security while at the same time solve the problem of having common files ADDed from one place.

Perhaps we could check to see if the (FQFN) is on a mounted device and allow that? Or some other magic.

[tianon]

I've updated the title here to reflect the issue that needs to be fixed here. :)

See #2745 for more discussion of why adding files outside the build context isn't and probably won't be supported.

[SvenDowideit]

its mildly more complicated.

ADD /file / works. it adds the file from the root of the context - so when you say ADD /etc/shadow /, Docker build is expecting that the user put an /etc/shadow file into the context.

[abhishiv]

This please! It wasn't obvious to me and I spend half a day fighting it.

[amitkumarj441]

@ipbabble I'm trying to build an image on ubuntu:latest and given below is the error :

lstat build: no such file or directory

Please do fix it.

[wilnauem]

The issue still persists for me...
Why has this issue been closed?

[thaJeztah]

@wilnauem the issue was closed because the documentation was updated to explain that an absolute path refers to an absolute path _within the build context_, not an absolute path on the host; https://github.com/docker/docker/pull/5762/files

Given this directory (e.g. /users/home/foo/project);

|-- Dockerfile
`-- hello
    `-- world.txt

FROM scratch
COPY /hello/world.txt /foo/bar.txt
COPY /users/home/foo/project /project

This dockerfile will;

• add hello/world.txt, from the build-context (the directory you specified as PATH on docker build), not from a "global" directory named "hello"
• produce an error that /users/home/foo/project does not exist (because there's no subdirectory users/home/foo/project

[wilnauem]

Thank you very much... now I get it

[nafg]

To be clear, are ADD X Y and ADD /X Y completely identical, or is there any subtle difference at all?

[nafg]

I.e. if absolute paths are relative to the context, and relative paths are (presumably) also relative to the context

[MikhailTymchukDX]

@thaJeztah
I totally agree with @nafg
If absolute path is relative, then why do we need it?
Throw an error "Docker does not support absolute paths with this operation." and remove unneeded documentation, so it will be obvious.

[thaJeztah]

Changing that format/handling would be a huge breaking change, breaking tons of existing Dockerfiles, so not an option.

[jvanlangen]

My dockerfile contains:

WORKDIR /mvcapp
COPY bin/release/netcoreapp1.1/publish .

Executes it with docker build -t mvcapp .

My output is:

COPY failed: stat /var/lib/docker/tmp/docker-builder096728530/bin/release/netcoreapp1.1/publish: no such file or directory

I'm running on windows, why does it replaces it to a absolute path, that doesn't exists on windows?

Anyone has an idea what is going wrong?

[deragon]

I wasted time discovering that absolute paths are not supported. Docker should generate a warning when an absolute path is found, and eventually a few release later, an error. Its much better than getting an unhelpful lstat: <path>: no such file or directory error message, with the root '/' removed in the path. The root '/' support (which isn't one) should be deprecated.

[sumitKash]

@wilnauem the issue was closed because the documentation was updated to explain that an absolute path refers to an absolute path _within the build context_, not an absolute path on the host; https://github.com/docker/docker/pull/5762/files

Given this directory (e.g. /users/home/foo/project);

|-- Dockerfile
`-- hello
    `-- world.txt

FROM scratch
COPY /hello/world.txt /foo/bar.txt
COPY /users/home/foo/project /project

This dockerfile will;

• add hello/world.txt, from the build-context (the directory you specified as PATH on docker build), not from a "global" directory named "hello"
• produce an error that /users/home/foo/project does not exist (because there's no subdirectory users/home/foo/project

The best explanation so far, thanks buddy.

[adam-roth]

Changing that format/handling would be a huge breaking change, breaking tons of existing Dockerfiles, so not an option.

That's fine, but also kind of missing the crux of the issue. People have use-cases that would be made easier if they had some way of reaching outside of the build context when adding content to their image, such as by using an absolute path.

Fair enough that ADD and COPY can't be used for this, due to how they've historically interpreted absolute paths. What about adding a new command that interprets absolute paths relative to the root of the host machine?