- 1 Arch Linux bootstrap-based Docker image build setup
- 2 docker0 Bridge gets no IP / no internet access in containers
- 3 Storage driver section regarding overlay2
- 4 Storage driver devicemapper clarification
- 5 Is stable (instead of Edge) branch of Docker available?
- 6 Root equivalent through other means than the docker group
- 7 Drop-in snippets instead of /etc/docker/daemon.json. Why?
- 8 no connectivity between containers
- 9 Docker service failed to start "Error initializing network controller: list bridge addresses failed: no available network"
Arch Linux bootstrap-based Docker image build setup
I have recently come up with an Arch Linux Docker base image build setup (https://github.com/czka/archlinux-docker), based on bootstrap tarball. Compared to the shell script approach (https://wiki.archlinux.org/index.php/Docker#Build_Image), it has the benefit of enabling Arch Linux Docker image builds on non-Arch hosts, and does not require root.
What do you think of it? I tried getting some attention on Arch forum (https://bbs.archlinux.org/viewtopic.php?pid=1667108#p1667108) but no reply yet. Maybe I'm re-inveting the wheel? I was thinking not, as no similar solution is documented here on the Wiki. Please let me know.
In the forum topic I mentioned I'm asking abot 3 things I need to sort out in order to call the whole thing done. I'll appreciate some input.
docker0 Bridge gets no IP / no internet access in containers
I want to rewrite this section: based on my experience with systemd 232 and Docker 1.13, creating /etc/systemd/network/ipforward.network file as suggested by that section introduces problems where bridges created by Docker loose their IP addresses once all containers using those bridges are stopped, and don't regain the IP. Ektich (talk) 09:42, 2 March 2017 (UTC)
Storage driver section regarding overlay2
The wording of Arch Linux using overlay2 suggests that the default storage driver is overlay2. From what I can tell, the default storage driver is devicemapper. Perhaps the section should say that there is work being done to make overlay2 the default storage driver and reference a Github issue or something like that. --Dmp1ce (talk) 01:21, 2 April 2017 (UTC)
Storage driver devicemapper clarification
It is true that devicemapper in loopback mode should never be used outside of development but if a proper LVM volume is being used (no loopback), performance is not degraded in any way. Devicemapper non-loopback is the preferred local storage driver on CentOS and RHEL. The wording should probably be changed to say that devicemapper is acceptable to use but there should be a proper backing for it and not just a loopback LVM volume. --MrOwen (talk) 23:19, 31 October 2017 (UTC)
Is stable (instead of Edge) branch of Docker available?
Root equivalent through other means than the docker group
I really wouldn't call myself good at docker so I don't feel confident enough to edit this myself. But as far as I've understood, the `root equivalent` warning in the Installation section should at least be added to the Remote API section and probably some others too. Or maybe not everywhere, but some sort of indication that the reader is playing with fire depending on how they configure docker. Powersource (talk) 06:38, 12 July 2017 (UTC)
The wiki instructs to *add* user to `docker` group to run docker as regular user and goes on to say that adding regular user to docker group would make it root equivalent. I think the two statements are conflicting. If the user is no longer *regular* after being added to docker group then it does not make sense to say you can even run docker as regular user.
There are multiple parts to Docker:
- The Docker Daemon (docker.service), a server process than runs as root
- The Docker CLI (docker command), a client process that runs as the user that invokes it
- The Docker container processes, which may run as any user as defined by the USER directive in the Dockerfile used to build the image
When you run a docker run command, the client tells the server to spawn a process. Since the server runs as root, it can spawn container processes that also run as root.
Adding a user to the docker group gives them permission to run the docker CLI command. This user could then escalate to root easily:
Write a Dockerfile:
FROM debian:9 USER root ADD payload.sh
Build an image from the Dockerfile, and run the image with `docker run myimage -v /:/host/`. A new Docker container process is spawned which runs as root and has root access to the entire host filesystem. payload.sh can now attack the system.
This is what User Remapping protects against- even if you run an image with USER root, instead of the Docker container running as root it runs as a random UID and GID from the remap range. Dharmab (talk) 16:23, 4 April 2020 (UTC)
PS. The client/server relationship applies even if you don't enable the Remote API. When you run docker locally the server listens through a Unix domain socket. You can also use the Docker API libraries to write code that communicates with the socket directly instead of using the CLI. More accurately, the docker group allows a user to access this domain socket. Dharmab (talk) 16:26, 4 April 2020 (UTC)
- I am afraid you are confusing the `User` directive in systemd with the `USER` directive in docker. In the latter, the directive is NOT used to set the user running the container but instead is the user which is used to run the service within the container, see the [official docker documentation](https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#user) for more information. Plus, by default the host FS is not mounted into the container but it can be and that is the whole point. Hence, you greater point is valid: having control over `docker.socket` is very much comparable to having root access, see this more in [depth discussion](https://docs.docker.com/engine/security/security/#docker-daemon-attack-surface). -- Edh (talk) 22:20, 4 April 2020 (UTC)
- I find your last edit to the user namespace section wrong. As far as I understand, the containers are not namespaced by default at all, so the UID/GID used inside the container corresponds exactly to the same UID/GID outside the container. Also, it does not matter if the same user/group name is assigned to each UID/GID inside and outside the container. The original wording was pretty clear and accurate, yours is not. -- Lahwaacz (talk) 17:59, 5 April 2020 (UTC)
Drop-in snippets instead of /etc/docker/daemon.json. Why?
Is there a reason for promotion of the systemd drop-in snippets in the Wiki page?
Not sure but https://docs.docker.com/engine/userguide/storagedriver/selectadriver/#check-and-set-your-current-storage-driver recommends using /etc/docker/daemon.json to set the storage engine. This approach seems more appropriate to me. --Michaelmcandrew (talk) 12:15, 18 December 2017 (UTC)
Both approaches are equally valid and supported: https://docs.docker.com/config/daemon/#configure-the-docker-daemon
no connectivity between containers
I experienced that docker containers started with docker-compose can not connect to each other (even on published ports). For me it only helped to disable ip tables filtering for bridges (which is not a good solution as it omits docker security (icc flag useless)
# echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables
Docker service failed to start "Error initializing network controller: list bridge addresses failed: no available network"
Good to add solution for:
dockerd: Error starting daemon: Error initializing network controller: list bridge addresses failed: no available network
which is following that commands:
#!/bin/bash # # create docker0 bridge # restart docker systemd service # confirm new outgoing NAT masquerade is set up # # reference # https://docs.docker.com/engine/userguide/networking/default_network/build-bridges/ # sudo brctl addbr docker0 sudo ip addr add 192.168.42.1/24 dev docker0 sudo ip link set dev docker0 up ip addr show docker0 sudo systemctl restart docker sudo iptables -t nat -L -n exit(0)
tested and works for me solution found at