aboutsummaryrefslogtreecommitdiff
path: root/module/(developers-only)
diff options
context:
space:
mode:
authorJesús Daniel Colmenares Oviedo <dtxdf@FreeBSD.org>2026-08-28 05:12:46 +0000
committerJesús Daniel Colmenares Oviedo <dtxdf@FreeBSD.org>2026-08-28 05:12:46 +0000
commit2c68ad49f13ddfa33735bd9bb6a3ca170a472ac0 (patch)
treeb90f52969bd635cdf5d64ab447218c2e2236fbf0 /module/(developers-only)
parentc869a36fc98a2ac1df5127e34ba7f9bffa0a5ce7 (diff)
nullfs: Allow VSOCK to be mounted on top of another VSOCKHEADmain
In the world of containers, mounting a unix(4) socket is a common practice to allow communication between processes within containers. For example, both Podman and Docker can expose a unix(4) socket, and that same unix(4) socket can be mounted as a file accessible to a process inside a container, allowing that application to control Podman or Docker. Another example is PHP-FPM with NGINX, where, instead of using TCP/IP for communication between containers, a unix(4) socket is sufficient. However, nullfs(4) and all related components do not allow mounting a VSOCK on top of another. The current workaround involves creating the socket in a directory and mounting that directory. This is an option, though it does not provide a good user experience compared to directly mounting a VSOCK on top of another, since the application that creates the socket may create other sockets in that directory, and the user may not wish to share them, or, worse yet, applications that create unix(4) sockets may not provide any authentication at all, as they may assume that security at the file system level is sufficient. Reviewed by: dfr@ Approved by: dfr@ Relnotes: yes Differential Revision: https://reviews.freebsd.org/D59158
Diffstat (limited to 'module/(developers-only)')
0 files changed, 0 insertions, 0 deletions