Add with relative path to parent directory fails with "Forbidden path"

[Sjord]

If you have an add line in the Dockerfile which points to another directory, the build of the image fails with the message "Forbidden path".

Example:

FROM tatsuru/debian
ADD ../relative-add/some-file /tmp/some-file

Gives:

$ ../bundles/0.6.6-dev/binary/docker-0.6.6-dev build .
Uploading context 20480 bytes
Step 1 : FROM tatsuru/debian
 ---> 25368de90486
Step 2 : ADD ../relative-add/some-file /tmp/some-file
Error build: Forbidden path: /tmp/relative-add/some-file

I would expect the file to be written to /tmp/some-file, not /tmp/relative-add/some-file.

[Sjord]

The build actually happens in /tmp/docker-12345, so a relative path like ../relative-add/some-file is relative to /tmp/docker-12345. It would thus search for /tmp/relative-add/some-file, which is also shown in the error message. It is not allowed to include files from outside the build directory, so this results in the "Forbidden path" message.

It was not clear to me that the directory is moved to another directory in /tmp before the build, or that the paths are resolved after moving the directory. It would be great if this can be fixed, or if the error message could be clearer. For example: "relative paths outside the sandbox are not currently supported" when supplying a relative path, or "The file %s is outside the sandbox in %s and can not be added" instead of "Forbidden path".

[tianon]

#2692 is a good first pass at making this more clear.

[bryanlarsen]

Sorry to hijack, but this seems completely broken to me. I've got a grand total of about 2 hours of Docker experience, so this is likely a problem with my understanding than docker.

I'm going to be creating approximately 10 images from our source tree. But to be able to use the ADD command, I would have to put the Dockerfile in the root of the tree, so only 1 image could be built. Not to mention the fact that this would result in a context of close to 100 megabytes.

I could do an ADD with URL's, but this would make it much more difficult for dev's to create images for testing purposes.

Another option would be to add source to the image via volumes instead of adding it, but this really seems contrary to the spirit of Docker.

It seems to me that one partial, easy solution would be to modify the build command so that the context and the Dockerfile could be specified separately.

[karellm]

Is there any reason for that change? Why can't we add files from the parent folder?

[wwoods]

I find this behavior fairly frustrating, especially for "meta" Dockerfiles. E.g. I have a /dev folder I do most work in, and I want /dev/environments git repo which has e.g. /dev/environments/main/Dockerfile. It's very annoying not allowing that Dockerfile to:

ADD ../../otherProject /root/project

To add /dev/otherProject as /root/project. Using an absolute path breaks sharing this Dockerfile with other developers.

[wwoods]

Another note - the only possible workaround I've found is to symlink the Dockerfile to the root /dev folder. This results in a very long and resource intensive "Uploading context" stage, which appears to (quite needlessly) copy all of the project directories to a temporary location. If the point of containers is isolation, and Dockerfiles (rightfully) don't seem to allow interacting with the build system, why does Docker need to copy all of the files? Why does it copy files that are not referenced in the Dockerfile at all?

[SvenDowideit]

@wwoods the short answer is that the docker client does not parse the Dockerfile. It tgz's the context (current dir and all subdirs) up, passed it all to the server, which then uses the Dockerfile in the tgz to do the work.

[wwoods]

That seems pretty flawed, in that it greatly restricts the viable scope of Dockerfiles. Specifically, it disallows Dockerfiles layered on top of existing code configurations, forcing users to structure their code around the Dockerfile rather than the other way around. I understand the reasoning behind allowing the daemon to be on a remote server, but it seems like it would greatly improve Docker's flexibility to parse the Dockerfile and upload only specified sections. This would enable relative paths and reduce bandwidth in general, while making usage more intuitive (the current behavior is not very intuitive, particularly when playing on a dev box).

[waysidekoi]

Would it be possible to amend an option flag that could allow users to manually add specific directories to expand the context?

[wwoods]

That would work, but again way less intuitive than just parsing the Dockerfile. Also, you're wasting a lot of upload bytes for no reason by uploading a lot of files you don't necessarily use.

[SvenDowideit]

@wwoods - even if the client were to parse the Dockerfile and work out what files to send and which to discard, we still can't afford to bust out of the current directory and let your builder access your client's entire file system.

There are other solutions to your scenario that don't increase our insecurity footprint.

either way, restricting the Dockerfile to the current context is not going to change, so I'm going to close this.

[wwoods]

How is it insecure to allow the builder to access files readable to the user? Why are you superseding linux file security? Please realize that this greatly limits the use cases of Docker and makes it much less enjoyable to add to existing workflows.

[unclejack]

@wwoods I set up a GitHub repository with code and a Dockerfile in it, you clone it to ~/code/gh-repos/, cd to ~/foobarbaz and run docker build -t foobarbaz .. Let's say I'm a bad guy and I add something like this to the Dockerfile: ADD .. /foo. The image will now contain your entire home directory and anything you might have there. Let's say the resulting image also ends up on the Internet on some registry. Everyone who has the image also has your data - browser history & cookies, private documents, password, public and private SSH keys, some internal company data and some personal data.

We're not going to allow Docker ADD to bust out of its context via .. or anything like it.