Feature RQ: Unix Domain Socket Proxying

[jrmoserbaltimore]

When reverse-proxying on the same system, such as through Docker, it is useful to use Unix domain sockets to proxy. You can share these via filesystem, e.g. through a shared volume.

This feature request suggests a way for proftpd mod_proxy to communicate with a proftpd mod_proxy on the same system, either running in a chroot() or in a Docker container, where each proftpd can access a shared directory in which to deposit Unix sockets.

Consider a front-end system (rproxy) and a back-end system (host).

Configuration

From the reverse proxy (rproxy), mod_proxy should allow a Unix domain socket as ProxyForwardTo.

ProxyForwardTo unix:/var/run/proftpd/proxy/myserver.sock

On the host (host), mod_proxy should allow the configuration of a Proxy socket path. This configuration would optimally support vhosts. It should also support a Proxy socket name.

ProxySocketPath /var/run/proftpd/proxy
ProxySocketListen myserver.sock

Behavior

Host

Note: The below is strictly conforming to POSIX standards and security recommendations. mkdtemp() does avoid a race condition which mkstemp() (and then unlink() and creation of the socket) would encounter.

When a connection to the host via mod_proxy Unix domain socket gets a PASV port, the host should use mkdtemp() to create a temporary subdirectory under ProxySocketPath of the form socket.XXXXXX. Within this directory, it should create a socket file. The host proxies any connection to this socket file directly to the local PASV port.

The host, when providing a PASV port to a client connected over Unix socket, will pass back the path under ProxySocketPath as the PASV address and port. For example, it would pass back socket.a7cjHN/pasv.sock rather than a host and port.

On initialization, mod_proxy should remove empty socket.* directories in the socket path.

Reverse Proxy

The reverse proxy (rproxy), being connected to the Unix socket, will interpret this as a path in the same directory as the socket. For example: it will interpret teCa9F.sock as /var/run/proftpd/proxy/teCa9F.sock, or socket.a7cjHN/pasv.sock as /var/run/proftpd/proxy/socket.a7cjHn/pasv.sock. As (rproxy) or (host) may be in a chroot() with the ProxySocketPath mounted at a different path, it will use the path to the directory containing the socket as the base path.

The above allows long-term discretion on naming sockets and on whether to put them into individual subdirectories, per-vhost subdirectories, or just all in one directory.

The reverse proxy will always request PASV mode in this configuration. In this way, the back-end proxy, running in a chroot() or Docker container, will create a Unix socket to accept each data connection (PASV over Unix socket). The front-end proxy doesn't need to handle connections by producing sockets; it only connects to them, thus simplifying implementation. Because no network is involved, there are no considerations to dictate whether Passive or Active FTP is appropriate.

[Castaglia]

An additional benefit of this approach is that the backend servers need not be exposed to the network in any way; they are only reachable (by FTP clients) via the proxy. Nice.