Support binding to a Unix domain socket

[nathanweeks]

For users who run tensorboard on a multi-user host (e.g., on a shared compute server, or HPC cluster as in this example), it would be beneficial for security to allow tensorboard to bind to a Unix domain socket (instead of a TCP port). File permissions on the socket file could be set to allow access only by the user that created it, and the user could securely access their tensorboard session on the remote host via Unix domain socket forwarding (which OpenSSH has supported since v6.7).

The Werkzeug dev server supports listening on a unix domain socket.

[bileschi]

Thanks for the suggestion @nathanweeks ! Could you provide a proposal for how the feature might work? There is some concern that the implementation may be complicated and difficult to maintain. We would want to balance the value against the complexity cost.

[nathanweeks]

From a CLI perspective, tensorboard could accept --host=unix:///path/to/tensorboard.sock, if possible setting permissions on the socket file to 700 after it's created (or alternatively documenting that users should specify a path in a directory with appropriate permissions).

If the client has direct SSH access to the remote host tensorboard is running on, an ssh command to port-forward localhost:6006 to the socket file could look like:

ssh -NL 6006:/path/to/tensorboard.sock [email protected] 

The user would open http://localhost:6006 in a web browser.

Or in the case where tensorboard is running in a batch or interactive job on a compute node in an HPC cluster, where compute nodes are generally not directly accessible from outside the cluster, the login node could usually be used as a jump host, e.g:

ssh -NL 6006:/path/to/tensorboard.sock -J remote.user@login-node remote.user@compute-node

[jhgoebbert]

This would also help to access Tensorboard (running on a multi-user compute node) through the JupyterLab extension jupyter-server-proxy as it supports proxying to a server process via a Unix socket: https://github.com/jupyterhub/jupyter-server-proxy/pull/337

[flxmr]

The Werkzeug dev server supports listening on a unix domain socket.

it does and for me it just seems to work fine when I change the info/logging-code to not expect a (host,port)-tuple. Will try it for a bit, then try a PR (not 100% sure what to do about the tests for TensorBoardInfo, which expects a port-number and works just fine if allowing None so far)