This fix tries to address the issue raised in #22271 where
relative symlinks don't work with --device argument.
Previously, the symlinks in --device was implemneted (#20684)
with `os.Readlink()` which does not resolve if the linked
target is a relative path. In this fix, `filepath.EvalSymlinks()`
has been used which will reolve correctly with relative
paths.
An additional test case has been added to the existing
`TestRunDeviceSymlink` to cover changes in this fix.
This fix is related to #13840 and #20684, #22271.
This fix fixes#22271.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: 632b314b239d1cd5e2498f198503a2983233a9f4
Component: engine
link feature in docker0 bridge by default provides short-id as a
container alias. With built-in SD feature, providing a container
short-id as a network alias will fill that gap.
Signed-off-by: Madhu Venugopal <madhu@docker.com>
Upstream-commit: ea531f061d3c511e376753f9863cb41f1b96d87e
Component: engine
People have reported following problem.
- docker run -ti --name=foo -v /dev/:/dev/ fedora bash
- docker cp foo:/bin/bash /tmp
Once the cp operation is complete, it unmounted /dev/pts on the host. /dev/pts
is a submount of /dev/. This is completely unexpected. Following is the
reson for this behavior.
containerArchivePath() call mountVolumes() which goes through all the mounts
points of a container and mounts them in daemon mount namespace in
/var/lib/docker/devicemapper/mnt/<containerid>/rootfs dir. And once we have
extracted the data required, these are unmounted using UnmountVolumes().
Mounts are done using recursive bind (rbind). And these are unmounted using
lazy mount option on top level mount. (detachMounted()). That means if there
are submounts under top level mounts, these mount events will propagate and
they were "shared" mounts with host, it will unmount the submount on host
as well.
For example, try following.
- Prepare a parent and child mount point.
$ mkdir /root/foo
$ mount --bind /root/foo /root/foo
$ mount --make-rshared /root/foo
- Prepare a child mount
$ mkdir /root/foo/foo1
$ mount --bind /root/foo/foo1 /root/foo/foo1
- Bind mount foo at bar
$ mkdir /root/bar
$ mount --rbind /root/foo /root/bar
- Now lazy unmount /root/bar and it will unmount /root/foo/foo1 as well.
$ umount -l /root/bar
This is not unintended. We just wanted to unmount /root/bar and anything
underneath but did not have intentions of unmounting anything on source.
So far this was not a problem as docker daemon was running in a seprate
mount namespace where all propagation was "slave". That means any unmounts
in docker daemon namespace did not propagate to host namespace.
But now we are running docker daemon in host namespace so that it is possible
to mount some volumes "shared" with container. So that if container mounts
something it propagates to host namespace as well.
Given mountVolumes() seems to be doing only temporary mounts to read some
data, there does not seem to be a need to mount these shared/slave. Just
mount these private so that on unmount, nothing propagates and does not
have unintended consequences.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Upstream-commit: cacd4007776672e918162936d8846eb51a5300e6
Component: engine
Following #19995 and #17409 this PR enables skipping userns re-mapping
when creating a container (or when executing a command). Thus, enabling
privileged containers running side by side with userns remapped
containers.
The feature is enabled by specifying ```--userns:host```, which will not
remapped the user if userns are applied. If this flag is not specified,
the existing behavior (which blocks specific privileged operation)
remains.
Signed-off-by: Liron Levin <liron@twistlock.com>
Upstream-commit: 6993e891d10c760d22e0ea3d455f13858cd0de46
Component: engine
This fixes an issue that caused the client to hang forever if the
process died before the code arrived to exit the `Kill` function.
Signed-off-by: David Calavera <david.calavera@gmail.com>
Upstream-commit: 1a729c3dd8e84eef0a0b10cab24e88b768557482
Component: engine
Moving all strings to the errors package wasn't a good idea after all.
Our custom implementation of Go errors predates everything that's nice
and good about working with errors in Go. Take as an example what we
have to do to get an error message:
```go
func GetErrorMessage(err error) string {
switch err.(type) {
case errcode.Error:
e, _ := err.(errcode.Error)
return e.Message
case errcode.ErrorCode:
ec, _ := err.(errcode.ErrorCode)
return ec.Message()
default:
return err.Error()
}
}
```
This goes against every good practice for Go development. The language already provides a simple, intuitive and standard way to get error messages, that is calling the `Error()` method from an error. Reinventing the error interface is a mistake.
Our custom implementation also makes very hard to reason about errors, another nice thing about Go. I found several (>10) error declarations that we don't use anywhere. This is a clear sign about how little we know about the errors we return. I also found several error usages where the number of arguments was different than the parameters declared in the error, another clear example of how difficult is to reason about errors.
Moreover, our custom implementation didn't really make easier for people to return custom HTTP status code depending on the errors. Again, it's hard to reason about when to set custom codes and how. Take an example what we have to do to extract the message and status code from an error before returning a response from the API:
```go
switch err.(type) {
case errcode.ErrorCode:
daError, _ := err.(errcode.ErrorCode)
statusCode = daError.Descriptor().HTTPStatusCode
errMsg = daError.Message()
case errcode.Error:
// For reference, if you're looking for a particular error
// then you can do something like :
// import ( derr "github.com/docker/docker/errors" )
// if daError.ErrorCode() == derr.ErrorCodeNoSuchContainer { ... }
daError, _ := err.(errcode.Error)
statusCode = daError.ErrorCode().Descriptor().HTTPStatusCode
errMsg = daError.Message
default:
// This part of will be removed once we've
// converted everything over to use the errcode package
// FIXME: this is brittle and should not be necessary.
// If we need to differentiate between different possible error types,
// we should create appropriate error types with clearly defined meaning
errStr := strings.ToLower(err.Error())
for keyword, status := range map[string]int{
"not found": http.StatusNotFound,
"no such": http.StatusNotFound,
"bad parameter": http.StatusBadRequest,
"conflict": http.StatusConflict,
"impossible": http.StatusNotAcceptable,
"wrong login/password": http.StatusUnauthorized,
"hasn't been activated": http.StatusForbidden,
} {
if strings.Contains(errStr, keyword) {
statusCode = status
break
}
}
}
```
You can notice two things in that code:
1. We have to explain how errors work, because our implementation goes against how easy to use Go errors are.
2. At no moment we arrived to remove that `switch` statement that was the original reason to use our custom implementation.
This change removes all our status errors from the errors package and puts them back in their specific contexts.
IT puts the messages back with their contexts. That way, we know right away when errors used and how to generate their messages.
It uses custom interfaces to reason about errors. Errors that need to response with a custom status code MUST implementent this simple interface:
```go
type errorWithStatus interface {
HTTPErrorStatusCode() int
}
```
This interface is very straightforward to implement. It also preserves Go errors real behavior, getting the message is as simple as using the `Error()` method.
I included helper functions to generate errors that use custom status code in `errors/errors.go`.
By doing this, we remove the hard dependency we have eeverywhere to our custom errors package. Yes, you can use it as a helper to generate error, but it's still very easy to generate errors without it.
Please, read this fantastic blog post about errors in Go: http://dave.cheney.net/2014/12/24/inspecting-errors
Signed-off-by: David Calavera <david.calavera@gmail.com>
Upstream-commit: a793564b2591035aec5412fbcbcccf220c773a4c
Component: engine
Currently, when running a container with --ipc=host, if /dev/mqueue is
a standard directory on the hos the daemon will bind mount it allowing
the container to create/modify files on the host.
This commit forces /dev/mqueue to always be of type mqueue except when
the user explicitely requested something to be bind mounted to
/dev/mqueue.
Signed-off-by: Kenfe-Mickael Laventure <mickael.laventure@gmail.com>
Upstream-commit: f7d4abdc00d521509995da1070215c808fe0fd9c
Component: engine
mqueue can not be mounted on the host os and then shared into the container.
There is only one mqueue per mount namespace, so current code ends up leaking
the /dev/mqueue from the host into ALL containers. Since SELinux changes the
label of the mqueue, only the last container is able to use the mqueue, all
other containers will get a permission denied. If you don't have SELinux protections
sharing of the /dev/mqueue allows one container to interact in potentially hostile
ways with other containers.
Signed-off-by: Dan Walsh <dwalsh@redhat.com>
Upstream-commit: ba38d58659cc155aebf89a2ea4cfc3cd7ba04a64
Component: engine
dockerinit has been around for a very long time. It was originally used
as a way for us to do configuration for LXC containers once the
container had started. LXC is no longer supported, and /.dockerinit has
been dead code for quite a while. This removes all code and references
in code to dockerinit.
Signed-off-by: Aleksa Sarai <asarai@suse.com>
Upstream-commit: 4357ed4a7363a1032edf93cf03232953c805184f
Component: engine
https://github.com/docker/libnetwork/pull/810 provides the more complete
solution for moving the Port-mapping ownership away from endpoint and
into Sandbox. But, this PR makes the best use of existing libnetwork
design and get a step closer to the gaol.
Signed-off-by: Madhu Venugopal <madhu@docker.com>
Upstream-commit: e38463b2779f455b4173171d5a1fdb115180a7e9
Component: engine
- Currently it is being save upfront...
Signed-off-by: Alessandro Boch <aboch@docker.com>
Upstream-commit: 733245b2e7517b88cdfb188f9d8418f29bca6338
Component: engine
Remove duplication checking for the existence of endpoint to speed up container starting
Upstream-commit: f292e90b8dcca4fabf9d6aa6d889e9fae0eca6ba
Component: engine
docker's network disconnect api now supports `Force` option which can be
used to force cleanup an endpoint from any host in the cluster.
Signed-off-by: Madhu Venugopal <madhu@docker.com>
Upstream-commit: b464f1d78cdfa2a4124e083b8f7b0f2353f12de3
Component: engine
This brings in the container-local alias functionality for containers
connected to u ser-defined networks.
Signed-off-by: Madhu Venugopal <madhu@docker.com>
Upstream-commit: e221b8a3d64c13178e156fc3ece5e9894dac1603
Component: engine
It's like `MemorySwappiness`, the default value has specific
meaning (default false means enable oom kill).
We need to change it to pointer so we can update it after
container is created.
Signed-off-by: Qiang Huang <h.huangqiang@huawei.com>
(cherry picked from commit 9c2ea42329179c589f5a8991ccf0253eb10fc897)
Conflicts:
vendor/src/github.com/docker/engine-api/types/container/host_config.go
Upstream-commit: f4a687334b1d026c84809fd005e1a82225d1c86f
Component: engine
