daemon/volumes.go
This SetFileCon call made no sense, it was changing the labels of any
directory mounted into the containers SELinux label. If it came from me,
then I apologize since it is a huge bug.
The Volumes Mount code should optionally do this, but it should not always
happen, and should never happen on a --privileged container.
The change to
daemon/graphdriver/vfs/driver.go, is a simplification since this it not
a relabel, it is only a setting of the shared label for docker volumes.
Docker-DCO-1.1-Signed-off-by: Dan Walsh <dwalsh@redhat.com> (github: rhatdan)
Upstream-commit: 4eb2fd169f8c9adbee4a9a0bd387f96b4e725963
Component: engine
In particular, the security implications.
Closes#5169
Signed-off-by: Doug Davis <dug@us.ibm.com>
Upstream-commit: 3c9425d40dbb069db9fe795eddc3fccfc62164f8
Component: engine
Added link to original issue and clarified text so someone without any
background on the original issue can understand why the test exists.
Docker-DCO-1.1-Signed-off-by: Phil Estes <estesp@linux.vnet.ibm.com> (github: estesp)
Upstream-commit: b5036ad5c64f19a52806df500b6a89d9c3294ac6
Component: engine
The overlay filesystem does not support inotify at this time. The
resolv.conf updater test was passing on overlay-based Jenkins because of
a fluke--because it was DIND, /etc/resolv.conf on the "host" was really
a bind-mounted resolv.conf from the outer container, which means a watch
directly on that file worked as it was not overlay backed. The new test
(from #10703) unmounts the bind-mounted copy to test create and modify
code-paths, which caused us to hit the issue.
This PR also adds a note to the docs about the lack of auto-update when
using the overlay storage driver.
See https://lkml.org/lkml/2012/2/28/223 for more info on inotify and
overlay.
Docker-DCO-1.1-Signed-off-by: Phil Estes <estesp@linux.vnet.ibm.com> (github: estesp)
Upstream-commit: 9057ca2541582fc41eb7cb45edd332247a813bba
Component: engine
make them reference to each other.
Signed-off-by: Chen Hanxiao <chenhanxiao@cn.fujitsu.com>
Upstream-commit: cbb149f52f5624cec41498398ab48c4043678707
Component: engine
See: https://github.com/docker/docker/issues/10867
While looking at #10867 I noticed that the error message generated for
a blank image ID wasn't very helpful so this fixes that.
Signed-off-by: Doug Davis <dug@us.ibm.com>
Upstream-commit: eeb36c9348b7af339638936a98d66ee4f9be62ee
Component: engine
Just format some logs and notes in /daemon/networkdriver/bridge/driver.g...
Upstream-commit: d64b009bc07e1adc550d40bd35efb0d2fc3e35e5
Component: engine
Closes#10807
Adds support for `dockerfile` ONLY when `Dockerfile` can't be found.
If we're building from a Dockerfile via stdin/URL then always download
it a `Dockerfile` and ignore the -f flag.
Signed-off-by: Doug Davis <dug@us.ibm.com>
Upstream-commit: 15924f238503ffe44e5fcb99415ff753a36e5971
Component: engine
and add a testcase to catch this in the future.
While in there I also:
- removed extra periods from the few options that had them (new test)
- made the --filter option consistent across all command
Signed-off-by: Doug Davis <dug@us.ibm.com>
Upstream-commit: 5595da2bde6574fe13785f07c55a155a2e90a7ca
Component: engine
when the file that was opened has been read into buffer, the file should be closed
Upstream-commit: 1500503b29d97257cf8c1789fc320e2409d9b394
Component: engine
Add the file close operation before function return to advoid resource leaking
Upstream-commit: 82aa950f4e10dbd45b16ecfc144f8d4b450ad1ff
Component: engine
