Skip to content

Conversation

@ahmetb
Copy link
Contributor

@ahmetb ahmetb commented Mar 16, 2015

This shows a warning message about adjusted file/directory permission bits
when the docker build cli command is executed on windows. This will help
Windows users understand the potential security problems.

We should be revisiting this warning when building against a Windows
docker engine. @jhowardmsft

Example:

Signed-off-by: Ahmet Alp Balkan [email protected]
cc: @tianon @tiborvass @ewindisch

@ahmetb
Copy link
Contributor Author

ahmetb commented Mar 16, 2015

@duglin TestBuildStderr (on Windows) doesn't seem like liked this (it wants to see stderr empty). Currently I'm using log.Warn which prints the warning to cli.Stderr. What do you advise for the docker build -q case and should we be writing to stdout instead?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no need for a variable use the string directly.

@ahmetb
Copy link
Contributor Author

ahmetb commented Mar 16, 2015

@tiborvass fixed your comments. waiting on @duglin's input on failing TestBuildStderr. I'm still not sure writing to stderr is OK in this case. log methods are not really extensively used in CLI code, so I'm suspicious.

@jessfraz jessfraz added this to the 1.6.0 milestone Mar 16, 2015
@duglin
Copy link
Contributor

duglin commented Mar 17, 2015

I think http://stackoverflow.com/questions/1430956/should-i-output-warnings-to-stderr-or-stdout is a good explanation for why warnings should go to stderr.
Can we modify the test so that if its running on windows we only accept that warning in the output and if anything else is there then we fail?

@ahmetb
Copy link
Contributor Author

ahmetb commented Mar 17, 2015

@duglin thanks for taking a look and suggesting to modify the test. I will basically say: if windows, all lines in stderr must begin with SECURITY WARNING:. do you have a better idea?

@duglin
Copy link
Contributor

duglin commented Mar 17, 2015

Yep - something like that should work since all we really care about is that the builder output doesn't show up there.

@ahmetb
Copy link
Contributor Author

ahmetb commented Mar 17, 2015

@duglin fixed. thanks.

@ewindisch
Copy link
Contributor

I'm generally okay with this and agree a message should be printed.

@duglin
Copy link
Contributor

duglin commented Mar 18, 2015

@ahmetalpbalkan test are failing

This shows a warning message about adjusted file/directory permission bits
when the `docker build` cli command is executed on windows.

Signed-off-by: Ahmet Alp Balkan <[email protected]>
@jessfraz
Copy link
Contributor

LGTM

@jessfraz
Copy link
Contributor

ping @duglin :D

@duglin
Copy link
Contributor

duglin commented Mar 20, 2015

LGTM

duglin added a commit that referenced this pull request Mar 20, 2015
Add cli build warning about chmod bits on windows
@duglin duglin merged commit c536e5b into moby:master Mar 20, 2015
@ahmetb ahmetb deleted the win-cli/build-warning branch March 20, 2015 23:21
thaJeztah added a commit to thaJeztah/cli that referenced this pull request Sep 5, 2025
relates to:

- moby/moby#11397
- moby/moby#18472

This warning was added in [moby@4a8b3ca] to print a warning when building
Linux images from a Windows client. Window's filesystem does not have an
"executable" bit, which mean that, for example, copying a shell script
to an image during build would lose the executable bit. So for Windows
clients, the executable bit would be set on all files, unconditionally.

Originally this was detected in the client, which had direct access to
the API response headers, but when refactoring the client to use a common
library in [moby@535c4c9], this was refactored into a `ImageBuildResponse`
wrapper, deconstructing the API response into an `io.Reader` and a string
field containing only the `OSType` header.

This was the only use and only purpose of the `OSType` field, and now that
BuildKit is the default builder for Linux images, this warning didn't get
printed unless BuildKit was explicitly disabled.

This patch removes the warning, so that we can potentially remove the
field, or the `ImageBuildResponse` type altogether.

[moby@4a8b3ca]: moby/moby@4a8b3ca
[moby@535c4c9]: moby/moby@535c4c9

Signed-off-by: Sebastiaan van Stijn <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants