Proxy unix socket?

Proposed change

Where jupyter-server-proxy launches a process, allow a configuration option to specify that the process will listen on a Unix socket rather than TCP/IP. By default, I would assume that JSP creates a temp directory and invites the child process to make a socket inside it.

Our JupyterHub instance (optionally) runs single-user servers on a shared node, with each user’s server running in their own system user account. In this scenario, I believe that once I’ve launched a proxied server, any other user can connect to it and make requests, either by going to /proxy/<portno>, or by running arbitrary code from a notebook or a terminal. I’d be happy to hear I’m wrong about this! Unix sockets can have permissions like files, so if you get these right, only the user a socket belongs to can connect to it.

This also avoids the race condition where the parent picks an unused port, but then something else binds it before the child can. The parent process instead creates a temp directory to pass to the child.

This could also be extended to the explicit proxying, to allow a Unix socket path in place of host+port. But that gets more complicated, because you need to work out how much of the URL is the socket path, and how much is the path to forward in the HTTP request.

This was touched on in #1, but the focus of that is different. https://gist.github.com/bdarnell/8641880 contains an example of using tornado AsyncHTTPClient with a Unix socket - it probably needs updating, but the tornado docs look like something similar should still work.

Alternative options

• Send some secret with the proxied requests which the application can check to validate that a request came through the right user’s proxy server. I think this is already possible by configuring request_headers_override. But it relies on every application which might be sensitive implementing the check, and all parties ensuring the secret doesn’t leak. Relying on the OS to block connections to Unix sockets seems safer - though I’m not a security expert.
• Ask the user to authenticate again in the proxied app, and use standard web app mechanisms to manage that. But part of why I’m interested in JSP is to avoid dealing with authentication, because users are already signed in to JupyterHub.
• Document the risks of using JSP where multiple users can share one node. 😞

Who would use this feature?

• Developers who want to expose a web app to a single JHub user, without implementing security mechanisms themselves
• Users who want to run a web app through JHub for their own use without letting other people act on their behalf

(Optional): Suggest a solution

• Check if the client code in the gist still works, update it as necessary
• Define the config for using a Unix socket and how it works with process launching (re-use {port} for the socket path? Or a new name?)
• Integrate support for launching a process with a Unix socket and proxying requests to it.

[ryanlovett]

I agree that this would be nice to have, even if not all web services support it. For example novnc/websockify (jupyter-desktop) supports unix sockets, but the open source version of rstudio (jupyter-rsession-proxy) does not.

One could theoretically lock down a web service within a network namespace to prevent unauthorized access but to set that up I think you’d need elevated privileges.

[takluyver]

I’ve had a go at this in #337.