if i run sudo dd if=/dev/zero of=/dev/sda in a docker container will my host system break?

Question

So I don't fully understand the level of isolation of a docker container, and wondering would this and other dangerous linux commands affect somehow my main machine (which is also linux of course)?

Answer 1

If you try this is a normal container, you'll see that there is no /dev/sda inside a container:

$ docker run -it --rm busybox
/ # ls -al /dev/sda
ls: /dev/sda: No such file or directory
/ # ls -al /dev
total 4
drwxr-xr-x    5 root     root           360 Jun 27 11:08 .
drwxr-xr-x    1 root     root          4096 Jun 27 11:08 ..
crw--w----    1 root     tty       136,   0 Jun 27 11:08 console
lrwxrwxrwx    1 root     root            11 Jun 27 11:08 core -> /proc/kcore
lrwxrwxrwx    1 root     root            13 Jun 27 11:08 fd -> /proc/self/fd
crw-rw-rw-    1 root     root        1,   7 Jun 27 11:08 full
drwxrwxrwt    2 root     root            40 Jun 27 11:08 mqueue
crw-rw-rw-    1 root     root        1,   3 Jun 27 11:08 null
lrwxrwxrwx    1 root     root             8 Jun 27 11:08 ptmx -> pts/ptmx
drwxr-xr-x    2 root     root             0 Jun 27 11:08 pts
crw-rw-rw-    1 root     root        1,   8 Jun 27 11:08 random
drwxrwxrwt    2 root     root            40 Jun 27 11:08 shm
lrwxrwxrwx    1 root     root            15 Jun 27 11:08 stderr -> /proc/self/fd/2
lrwxrwxrwx    1 root     root            15 Jun 27 11:08 stdin -> /proc/self/fd/0
lrwxrwxrwx    1 root     root            15 Jun 27 11:08 stdout -> /proc/self/fd/1
crw-rw-rw-    1 root     root        5,   0 Jun 27 11:08 tty
crw-rw-rw-    1 root     root        1,   9 Jun 27 11:08 urandom
crw-rw-rw-    1 root     root        1,   5 Jun 27 11:08 zero

This is an important reason why you want to avoid privileged containers since they are implicitly not isolated from the host:

$ docker run -it --rm --privileged busybox
/ # ls -al /dev/
total 4
drwxr-xr-x   14 root     root          3960 Jun 27 11:09 .    
drwxr-xr-x    1 root     root          4096 Jun 27 11:09 ..
crw-------    1 root     root       10,  58 Jun 27 11:09 acpi_thermal_rel
crw-r--r--    1 root     root       10, 235 Jun 27 11:09 autofs
crw-rw----    1 root     disk       10, 234 Jun 27 11:09 btrfs-control
drwxr-xr-x    3 root     root            60 Jun 27 11:09 bus  
crw--w----    1 root     tty       136,   0 Jun 27 11:09 console        
lrwxrwxrwx    1 root     root            11 Jun 27 11:09 core -> /proc/kcore
drwxr-xr-x   10 root     root           220 Jun 27 11:09 cpu   
crw-------    1 root     root       10,  62 Jun 27 11:09 cpu_dma_latency
crw-------    1 root     root       10, 203 Jun 27 11:09 cuse 
brw-rw----    1 root     disk      254,   0 Jun 27 11:09 dm-0 
brw-rw----    1 root     disk      254,   1 Jun 27 11:09 dm-1
brw-rw----    1 root     disk      254,   2 Jun 27 11:09 dm-2  
drwxr-xr-x    2 root     root            80 Jun 27 11:09 dri 
crw-------    1 root     root      245,   0 Jun 27 11:09 drm_dp_aux0    
crw-------    1 root     root      245,   1 Jun 27 11:09 drm_dp_aux1
crw-------    1 root     root      245,   2 Jun 27 11:09 drm_dp_aux2
crw-rw----    1 root     44         29,   0 Jun 27 11:09 fb0  
...

---

Also, you will find that most images do not include sudo . Either you are root, or you are an unprivileged user without the ability to escalate privileges inside the container. When running what is typically a single user environment, there's no need to include that privilege escalation, and if you did, that container user would effectively be root inside the container so there's no need to run as the user. If you need root on an already running container, the standard debugging/development practice is from outside the container to exec in with that added access:

docker exec -it -u root ${container_id_or_name} /bin/sh