Devices: mknod & bind mount are not the same

[alban]

The spec about devices says:

devices (array of objects, OPTIONAL) lists devices that MUST be available in the container. The runtime MAY supply them however it likes (with mknod, by bind mounting from the runtime mount namespace, using symlinks, etc.).

For most devices, choosing mknod or bind mount does not matter: the same feature will be provided. But for fifo files (type p) it's different: in one case, the container can communicate with the outside (bind mount), in the other case it can't (mknod). I'd suggest to remove pipes from the spec, unless the expected behaviour is clarified. I don't see a use case for it.

Also, some character devices (/dev/ptmx) are different whether they are bind mounted or a new one is created with mknod. Maybe some other character devices too. If the runtime is given freedom which one to use, maybe the spec could acknowledge that the behaviour might be different?

I don't understand the mention of symlinks: I don't see how symlinks can make device files available in the container.

runc will use normally use mknod unless the container is in a non-init userns; in this case it will use a bind mount because mknod is restricted in user namespaces.

[cyphar]

I'd suggest to remove pipes from the spec, unless the expected behaviour is clarified. I don't see a use case for it.

I think excluding FIFOs wouldn't make much sense, since it's part of the set of features you get with mknod with no really strong reason to not allow it.

Using bind-mounts for a FIFO could mean a variety of things. Personally I think that (as most cases in the OCI specs) there isn't a strong need to tell implementations precisely what is the most sane thing to do -- obviously bind-mounting to a random FIFO on the host is a horrific thing to do. But adding more text to explain that this is only allowed in "reasonable" circumstances wouldn't make much of an impact on how certification would work -- what defines "reasonable"?

I don't see how symlinks can make device files available in the container.

You could use symlinks to provide /dev/ptmx (by symlinking to /dev/pts/ptmx) for instance. I don't think that a reasonable reading of the spec would imply you can symlink to the host filesystem.