UNIX domain socket support in a non-exclusive way #635
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Opening TCP sockets, even locally, is somewhat tricky from a security point of view (see #286)... especially when connecting to remote Lisps when we don't want to close the port immediately.
#291 was aiming to solve this problem by switching over to UNIX domain sockets entirely when connecting to Lisps on UNIX systems, and sticking with TCP ports e.g. on Windows. However, this doesn't account for cases when we'd still want to keep using TCP ports on UNIX; also, its author is not interested in working on this anymore.
This PR follows a slightly different approach: instead of replacing the existing, TCP-based connection mechanism, it adds UNIX domain sockets as an additional, optional mechanism. We still connect to local Lisps via TCP; the use case for this is long-running Lisp images on servers, that we'd want to connect to remotely (e.g. by using ssh to forward the UNIX socket, or wrapping it into a client-cert-checked SSL tunnel using e.g. socat). It's definitely possible to use this sort of mechanism for local Lisps too in the future; it's just not being done yet, to keep things simple (& avoid breaking too many things).
I also added a test to make sure that this does in fact work, end to end.
It currently only supports SBCL; I can definitely put in backend functions for other Lisps, too, before merging, if you think this entire PR is a good idea in general (... if it isn't, universal support is kinda pointless :) so the first commit is mainly to start a discussion.)
Thanks for taking a look!