According to https://golang.org/src/runtime/symtab.go?s=3423:3455#L94
It is possibile that runtime.FuncForPC() returns nil, don't know how
but I do met this problem when some kernel config problems cause
`p.createNetworkInterfaces` return error.
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x0]
goroutine 74 [running]:
github_com_docker_libcontainer_stacktrace.NewFrame
/go/src/github.com/docker/docker/vendor/src/github.com/docker/libcontainer/stacktrace/frame.go:12
github_com_docker_libcontainer_stacktrace.Capture
/go/src/github.com/docker/docker/vendor/src/github.com/docker/libcontainer/stacktrace/capture.go:18
libcontainer.newSystemError
/go/src/github.com/docker/docker/vendor/src/github.com/docker/libcontainer/generic_error.go:48
github_com_docker_libcontainer.start.pN42_github_com_docker_libcontainer.initProcess
/go/src/github.com/docker/docker/vendor/src/github.com/docker/libcontainer/process_linux.go:177
github_com_docker_libcontainer.Start.pN45_github_com_docker_libcontainer.linuxContainer
/go/src/github.com/docker/docker/vendor/src/github.com/docker/libcontainer/container_linux.go:102
github_com_docker_docker_daemon_execdriver_native.Run.pN56_github_com_docker_docker_daemon_execdriver_native.driver
/go/src/github.com/docker/docker/.gopath/src/github.com/docker/docker/daemon/execdriver/native/driver.go:149
github_com_docker_docker_daemon.Run.pN38_github_com_docker_docker_daemon.Daemon
/go/src/github.com/docker/docker/.gopath/src/github.com/docker/docker/daemon/daemon.go:1007
github_com_docker_docker_daemon.Start.pN48_github_com_docker_docker_daemon.containerMonitor
/go/src/github.com/docker/docker/.gopath/src/github.com/docker/docker/daemon/monitor.go:138
promise.$nested0
/go/src/github.com/docker/docker/.gopath/src/github.com/docker/docker/pkg/promise/promise.go:8
created by github_com_docker_docker_pkg_promise.Go
/go/src/github.com/docker/docker/.gopath/src/github.com/docker/docker/pkg/promise/promise.go:7
Signed-off-by: Qiang Huang <h.huangqiang@huawei.com>
Allowing mounts in containers is dangerous. Bugs in
mount namespaces or quirks of the container configuration
could allow for various breakouts.
By default, processes in containers will not be able to mount anyway,
rendering the allowances in the default AppArmor profile nearly
useless. Manually created sub-containers were able to mount, but
were yet restricted from performing most of the mounts flags indicated
in the profile.
Signed-off-by: Eric Windisch <eric@windisch.us>
We need to do this incase /dev/null is a symlink pointing somewhere
outside the container's rootfs.
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
User specified mounts much be evaluated after each mount because
symlinks in nested mounts can invalidate the next mount.
Also check that any bind mounts are not inside /proc or /sys to ensure
that we are able to mask over certian paths inside.
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
If the seed was not seted, all machines get the same MAC address.
Then technique like Open vSwitch won't work due to the same MAC address
of all machines.
Signed-off-by: Shiao-An Yuan <shiao.an.yuan@gmail.com>
libcontainer/configs is used by the docker user namespace proposed
patchset to use IDMap for uid/gid maps across the codebase. Given the
client uses some of this code, it needs to build on non-Linux. This
separates out the Linux-only syscalls using build tags.
Signed-off-by: Phil Estes <estesp@linux.vnet.ibm.com> (github: estesp)
We do this aim two goals:
- don't fail when some subsystems are not mounted (devices cgroup
is an exception because it will cause secirity issues).
- fail hard instead of ignoring the error when a user specifies
an option and we are unable to fulfill the request.
Signed-off-by: Qiang Huang <h.huangqiang@huawei.com>
Qiang Huang
Ma Shimiao
Victor Marmol
Mrunal Patel
Michael Crosby
Alexander Morozov
Eric Windisch
Alexander Morozov
Michael Crosby
Andrey Vagin
Tianon Gravi
sayuan
Phil Estes
Daniel, Dao Quang Minh
Mrunal Patel