The error type libnetwork.ErrNoSuchNetwork is used in the controller
to retry the network creation as a managed network though the manager.
The change of the type was breaking the logic causing the network to
not being created anymore so that no new container on that network
was able to be launched
Added unit test
Signed-off-by: Flavio Crisciani <flavio.crisciani@docker.com>
(cherry picked from commit 51cea0a53c2fd36832277402e9faac81bfb4abd4)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Signed-off-by: Yu-Ju Hong <yjhong@google.com>
(cherry picked from commit 4b6ec10b07c14e7fff1cc51156b6d954147f826f)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Signed-off-by: John Stephens <johnstep@docker.com>
(cherry picked from commit 8ed8f4a71d7e1a936fa077b4348b7375c81746a6)
Conflicts:
components/engine/distribution/pull_v2_windows.go
Signed-off-by: John Stephens <johnstep@docker.com>
Update logic to choose manifest from manifest list to check
for os version on Windows. Separate the logic for windows
and unix to keep unix logic the same.
Signed-off-by: Derek McGowan <derek@mcgstyle.net>
(cherry picked from commit 38aef56e1fcb8ea318df98c89cf002267b88a136)
Signed-off-by: John Stephens <johnstep@docker.com>
This test case is checking that the built-in default size for /dev/shm
(which is used for `--ipcmode` being `private` or `shareable`)
is not overriding the size of user-defined tmpfs mount for /dev/shm.
In other words, this is a regression test case for issue #35271,
https://github.com/moby/moby/issues/35271
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
(cherry picked from commit 2e0a98b605fa278ee1f348c68fe7e07aed57b834)
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Commit 7120976d74195 ("Implement none, private, and shareable ipc
modes") introduces a bug: if a user-specified mount for /dev/shm
is provided, its size is overriden by value of ShmSize.
A reproducer is simple:
docker run --rm
--mount type=tmpfs,dst=/dev/shm,tmpfs-size=100K \
alpine df /dev/shm
This commit is an attempt to fix the bug, as well as optimize things
a but and make the code easier to read.
https://github.com/moby/moby/issues/35271
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
(cherry picked from commit 31d30a985d99a0eef92116a22159727f5c332784)
In order to avoid reverting our fix for mount leakage in devicemapper,
add a test which checks that devicemapper's Get() and Put() cycle can
survive having a command running in an rprivate mount propagation setup
in-between. While this is quite rudimentary, it should be sufficient.
We have to skip this test for pre-3.18 kernels.
Signed-off-by: Aleksa Sarai <asarai@suse.de>
(cherry picked from commit 1af8ea681fba1935c60c11edbbe19b894c9b286f)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
libdm currently has a fairly substantial DoS bug that makes certain
operations fail on a libdm device if the device has active references
through mountpoints. This is a significant problem with the advent of
mount namespaces and MS_PRIVATE, and can cause certain --volume mounts
to cause libdm to no longer be able to remove containers:
% docker run -d --name testA busybox top
% docker run -d --name testB -v /var/lib/docker:/docker busybox top
% docker rm -f testA
[fails on libdm with dm_task_run errors.]
This also solves the problem of unprivileged users being able to DoS
docker by using unprivileged mount namespaces to preseve mounts that
Docker has dropped.
Signed-off-by: Aleksa Sarai <asarai@suse.de>
(cherry picked from commit 92e45b81e0a8b68d9567a2068247460a1ba59600)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
83c2152de503012195bd26069fd8fbd2dea4b32f sets the kernel param for
fs.may_detach_mounts, but this is not neccessary for the daemon to
operate. Instead of erroring out (and thus aborting startup) just log
the error.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
(cherry picked from commit c6a2044497e0e1ff61350859c8572a2c31c17ced)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Commit 8d1ae76dcbbb73d8e20c6a14a7d3fe2410b95f55 added
deprecation warnings for empty continuation lines,
but also treated comment-only lines as empty.
This patch distinguishes empty continuation lines
from comment-only lines, and only outputs warnings
for the former.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 2fd736ac10c1c46d1001373d887cb99b3d8ee824)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
With `rprivate` there exists a race where a reference to a mount has
propagated to the new namespace, when `rprivate` is set the parent
namespace is not able to remove the mount due to that reference.
With `rslave` unmounts will propagate correctly into the namespace and
prevent the sort of transient errors that are possible with `rprivate`.
This is a similar fix to 117c92745b
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
(cherry picked from commit 5ede64d63fec0b9d4cf921b6f8fb946e65287538)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
While this code was likely called from a single thread before, we have
now seen panics, indicating that it could be called in parallel. This
change adds a mutex to protect opening and closing of the channel. There
may be another root cause associated with this panic, such as something
that led to the calling of this in parallel, as this code is old and we
had seen this condition until recently.
This fix is by no means a permanent fix. Typically, bugs like this
indicate misplaced channel ownership. In idiomatic uses, the channel
should have a particular "owner" that coordinates sending and closure.
In this case, the owner of the channel is unclear, so it gets opened
lazily. Synchronizing this access is a decent solution, but a refactor
may yield better results.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
(cherry picked from commit 5b55747a523671fa6e626848060460a48d058451)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Refactor to support testing
Also add tests
Signed-off-by: Daniel Nephin <dnephin@docker.com>
(cherry picked from commit e828efa4ab)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This test tries to pull all the tags in the busybox repo and looks to see
if there were more than two images pulled. This was failing on
p/z due to the recent change to manifest lists, where one of the busybox
tags didn't have a p/z manifest in it's manifest list.
This error seems fine to me, so I changed the test to see if pull fails,
it fails with the "manifest not found" error.
Also switched from busybox -> alpine, because it has significantly less tags,
and the images are close in size.
Signed-off-by: Christopher Jones <tophj@linux.vnet.ibm.com>
(cherry picked from commit 5739ba1b918402b8eda748ac2f5dd7ce00f2e69f)
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
To ensure that we don't revert CVE-2017-14992, add a test that is quite
similar to that upstream tar-split test (create an empty archive with
lots of junk and make sure the daemon doesn't crash).
Signed-off-by: Aleksa Sarai <asarai@suse.de>
(cherry picked from commit 0a13f827a10d3bf61744d9b3f7165c5885a39c5d)
Signed-off-by: Victor Vieux <victorvieux@gmail.com>
