Which `docker run` flag grants a container one host device without `--privileged`, and what do its rwm bits mean?

## The default: a deny-list you rarely notice Every container starts with a device cgroup that denies access to host devices, plus a small allow-list Docker sets up so that ordinary programs work: `/dev/null`, `/dev/zero`, `/dev/full`, `/dev/random`, `/dev/urandom`, `/dev/tty`, `/dev/console`, `/dev/ptmx` and the `/dev/shm` mount. That is why a container cannot open `/dev/sda` or a serial port even when its process runs as root — the node is absent, and even if it existed the cgroup would refuse the open. This is the confinement that `--privileged` throws away. Among other things, `--privileged` allows every device on the host, which is why the correct answer to "my container needs the USB serial adapter" is never `--privileged`. ## The narrow grant ```bash docker run --device /dev/ttyUSB0:/dev/ttyUSB0:rw reader:2.1 ``` The three colon-separated fields are: the path on the host, the path inside the container (defaults to the same path), and the permissions. The permission string is any subset of: - **r** — read from the device. - **w** — write to the device. - **m** — mknod: create a device node with this major:minor number. Omit the field and Docker grants `rwm`. That default is worth knowing, because a container that only needs to read a sensor gets write access it never asked for unless you spell out `:r`. Dropping `m` is nearly free and removes the ability to conjure fresh nodes for the same device. Mechanically, Docker does two things: it creates the node inside the container's `/dev` with the same major:minor and mode as the host's, and it adds an allow rule for that major:minor to the container's device cgroup. Both are needed — a node without a cgroup rule fails to open, and a rule without a node has nothing to open. ## Devices that are not there yet `--device` resolves the host path at container creation time. A device that appears later — a USB adapter replugged, a dynamically created node — will not be usable, because the container's `/dev` is a private mount that does not track the host. For that case `--device-cgroup-rule` pre-authorises a class of numbers: ```bash docker run --device-cgroup-rule 'c 189:* rmw' -v /dev/bus/usb:/dev/bus/usb usb-tool:1.9 ``` Here `c` is a character device, `189:*` is every minor under that major number, and `rmw` the permissions. Note that the rule authorises; something still has to make the node visible inside the container. This is deliberately a wider grant than a single `--device`, so use it only when a fixed node genuinely will not work. ## Permissions still apply The device cgroup is not the only gate. The node inside the container inherits the host's owner and mode, so a serial port owned `root:dialout 0660` is unreadable to a container process running as an unprivileged UID that is not in that group. The fix is `--group-add` with the numeric GID from the host (group *names* mean nothing across the boundary — the container's `/etc/group` is its own). Reaching for root inside the container instead is the answer that gives back what the grant was meant to contain. ## Where this comes up Serial and USB peripherals on edge hardware, a tun/tap node for a VPN client, a raw block device for a storage benchmark, an FPGA or accelerator node. Accelerators are usually not wired up with raw `--device` at all: a vendor container runtime hook injects the right set of nodes and libraries, because the grant is more than one file. Knowing that distinction — narrow static node via `--device`, vendor hook for accelerator stacks — is the practical takeaway. ## The interview shape This is rarely a screening question. It shows up when the role touches hardware, edge devices or storage, and what is really being tested is whether you reach for `--privileged` as a reflex. The strong answer is short: name the flag, name the three permission bits, mention that the default is all three, and note that the file mode on the node still has to permit the container's user.