Moby: Security warning appearing when building a Docker image from Windows against a non-Windows Docker host

[tomasmelin]

I am experimenting with building my own Docker image with the purpose of later building Jenkins and SonarQube dockers.

When I attempt to create a simple Dockerfile to experiment and install emacs to easily be able to edit files in bash I get the following output:

…
Setting up colord (1.0.6-1) ...
Setting up gconf-service (3.2.6-0ubuntu2) ...
Setting up emacs24 (24.3+1-2ubuntu1) ...
update-alternatives: using /usr/bin/emacs24-x to provide /usr/bin/emacs (emacs) in auto mode
Install emacsen-common for emacs24
emacsen-common: Handling install of emacsen flavor emacs24
Wrote /etc/emacs24/site-start.d/00debian-vars.elc
Wrote /usr/share/emacs24/site-lisp/debian-startup.elc
Setting up emacs (45.0ubuntu1) ...
Setting up gconf-service-backend (3.2.6-0ubuntu2) ...
Processing triggers for libc-bin (2.19-0ubuntu6.6) ...
Processing triggers for sgml-base (1.26+nmu4ubuntu1) ...
Processing triggers for libgdk-pixbuf2.0-0:amd64 (2.30.7-0ubuntu1.2) ...
---> 91050783b5ea
Removing intermediate container 38a6c797bbdb
Step 4 : CMD /usr/games/fortune -a | cowsay
---> Running in 1dd25d8bcf95
---> a874940ac99e
Removing intermediate container 1dd25d8bcf95
Successfully built a874940ac99e
SECURITY WARNING: You are building a Docker image from Windows against a non-Windows Docker host. All files and directories added to build context will have '-rwxr-xr-x' permissions. It is recommended to double check and reset permissions for sensitive files and directories.

This is what my dockerfile contains:

FROM docker/whalesay:latest

RUN apt-get -y update && apt-get install -y fortunes
RUN apt-get update && apt-get install -y emacs

CMD /usr/games/fortune -a | cowsay

What does this Security warning mean exactly and how can I avoid it?

More info, when I use the docker info command I get the following data:

$ docker info
Containers: 4
Running: 1
Paused: 0
Stopped: 3
Images: 6
Server Version: 1.10.1
Storage Driver: aufs
Root Dir: /mnt/sda1/var/lib/docker/aufs
Backing Filesystem: extfs
Dirs: 55
Dirperm1 Supported: true
Execution Driver: native-0.2
Logging Driver: json-file
Plugins:
Volume: local
Network: bridge null host
Kernel Version: 4.1.17-boot2docker
Operating System: Boot2Docker 1.10.1 (TCL 6.4.1); master : b03e158 - Thu Feb 11 22:34:01 UTC 201
OSType: linux
Architecture: x86_64
CPUs: 1
Total Memory: 1.956 GiB
Name: default
ID: NKSE:6GZL:N7AE:47Q5:HBAF:CERC:MHWZ:HWEC:QSVI:FTK5:P2E2:HRM3
Debug mode (server): true
File Descriptors: 27
Goroutines: 44
System Time: 2016-02-17T13:57:00.11534859Z
EventsListeners: 1
Init SHA1:
Init Path: /usr/local/bin/docker
Docker Root Dir: /mnt/sda1/var/lib/docker
Labels:
provider=virtualbox

[cpuguy83]

IIRC, this really has to do with COPY and ADD from files local to the Windows system.

Closing since this is not really an issue, but feel free to discuss here.

[thaJeztah]

That warning was added, because the Windows filesystem does not have an option to mark a file as 'executable'. Building a linux image from a Windows machine would therefore break the image if a file has to be marked executable.

For that reason, files are marked executable by default when building from a windows client; the warning is there so that you are notified of that, and (if needed), modify the Dockerfile to change/remove the executable bit afterwards.

[tomasmelin]

Thank you @thaJeztah for your explanatory response.

[MartinJohns]

Is there a way to prevent this warning? Some kind of switch?

[thaJeztah]

Is there a way to prevent this warning? Some kind of switch?

no, there's currently no switch to turn off that warning

[RobSeder]

There definitely NEEDS to be a switch. This helpful, and un-addressable message breaks the build when using automated build systems. If they see anything written to stderr or get a non-zero return code, that breaks the build.

If you give an error message either: A) give me a way to correct it or B) give me a way to suppress it. This needs to be fixed, this is a showstopper for those using Jenkins, TeamCity, Octopus, etc for builds.

Please re-open and address this.

[thaJeztah]

@RobSeder this message is now printed on stdout instead of stderr, starting with docker 17.04; see https://github.com/moby/moby/issues/29209, https://github.com/moby/moby/pull/29857, and https://github.com/moby/moby/pull/29856

[RobSeder]

@thaJeztah Agreed - this is resolved in 17.04. thanks!

[thaJeztah]

Thanks for checking @RobSeder 👍

[bdzevel]

(1.5 years later) - this doesn't quite fix it for me as I fail my builds on warnings so this warning message breaks my build. I've done it this way in order to fail builds that introduce any standards violations or other Microsoft compile-time warnings. So my only solution is to allow builds through with warnings? @thaJeztah

[thaJeztah]

@bdzevel as of docker 17.04, the warning should be printed on stdout, not stderr (see my comment above) so you could check stderr for messages (or check the exit-code).

[KhaledFarhat]

does this warning have any impact on the access for docker during the run that happens after the build? for example when i build an image locally (that does output the warning mentioned above) and try to run a container off of that image, docker fails to detect some files that do actually exist, i was able to verify the files existence when i sh into that container. @thaJeztah

[thaJeztah]

No this warning is just to indicatie files will be copied with the executable bit set (when using a Windows client)

If the command cannot be found and you're trying to execute a script, make sure the file has the correct line endings

[WilliamDenniss]

I too would like a way to suppress/acknowledge this "recommendation". It looks scary during public demos, and makes it seem like you're doing something wrong when in fact this message is just always printed regardless.

[DeveshwarH1996]

Hey, I have been running into a similar problem, when I build a linux image it is showing that all the files only have permission to execute, however in the image that I am building one of the folders need write permission. Is it possible to modify the permission from only -x- to -rwx- or at least -wx-

Thanks in advance for your help

[DeveshwarH1996]

@thaJeztah, do you have any suggestions???

[hamzahkhan]

\n\nWaiting for the systems to be ready..
...............................
WARNING: Could not reach configured kafka system on http://localhost:8082
Note: This script requires curl.
Stuck here

[romeuflores]

How about improving the ADD command to take unix umask parameters and setting them appropriately?

Or is there such a possibility already?

[thaJeztah]

How about improving the ADD command to take unix umask parameters and setting them appropriately?

See https://github.com/moby/moby/issues/34819

[sujithmp]

Hi I have a doubt regarding the directory to which people copy the file. I have noticed some using opt directory, other's use var/www/ and quite few uses usr directory. @thaJeztah is there any reason behind this? Which one is the proper way?

[thaJeztah]

@sujithmp all depends on the base image you're using to build your image; there's no one answer to that, and it's definitely not related to this ticket.

Please keep in mind that the GitHub issue tracker is not intended as a general support forum,
but for reporting bugs and feature requests. For other type of questions, consider using one of;

• the Docker Support Forums - https://forums.docker.com
• the Docker community Slack channel

[c33s]

what about having a simple environment variable DOCKER_SUPPRESS_WINDOWS_FILE_SECURITY_WARNING=TRUE?

[maulberto3]

Hi @thaJeztah I develop in Python app in Windows, works local fine, but when I deploy to Azure, it errors out, can't find index.py and other automatic commands, for some reason it doens't want to read my startup command, which works locally, again, would you say it's related to the security warning pf this ticket?

[thaJeztah]

No the warning should have no impact on the actual image. If files are not found, double check if they're not excluded by a .dockerignore. Another reason can be incorrect line-endings; if you're building a linux image, make sure your files use linux line-endings, not windows, otherwise Linux may produce confusing errors like that.

[iocoder]

I agree with @c33s. There must be a switch to suppress the warning.

We got the warnig. Message delivered, thanks. No need to say it again every time we run our docker-based autmated scripts.

Also the warning message is ugly: it doesn't even align with 80-columns-are-enough rule. It makes the log look creepy... photo attached showing how a simple docker build --help doesn't use more than 80 columns per line.

Also, got to mention that the message is distracting. Some times we have stuff to be printed to the log after docker build... These long message moves your focus away while you are skimming through the log.

[Zero3]

@thaJeztah any comment on the multiple requests above for a way to disable this warning? :)

[iocoder]

Same as @Zero3. Would be useful @thaJeztah if we can consider this.

[sujithmp]

If the command cannot be found and you're trying to execute a script, make sure the file has the correct line endings. What does that mean? Can u explain? @thaJeztah

[thaJeztah]

@sujithh Linux produces odd error messages if a script has Windows (CRLF) instead of Linux (LF) line-endings (https://en.wikipedia.org/wiki/Newline)

Here's a script with linux (LF or \n) line-endings;

echo -e '#!/bin/sh\necho hello' > linux.sh && chmod +x linux.sh
./linux.sh
# hello

And here's a script with Windows (CRLF or \r\n) line-endings;

echo -e '#!/bin/sh\r\necho hello' > windows.sh && chmod +x windows.sh
./windows.sh
# bash: ./windows.sh: /bin/sh^M: bad interpreter: No such file or directory