by denysonique on 11/27/23, 12:05 PM with 51 comments
by _flux on 11/27/23, 12:10 PM
In addition you can rely on Unix access control with the socket. Much better than granting access to all local users, such as is the case by default with e.g. Syncthing.
OpenSSH can also forward these sockets, so remote use can be safer that way and the port configuration issue is relevant here as well.
I've also hoped that NFS and its ilk would be able to transfer Unix domain sockets, but I haven't heard of a system that could do that. Then one could, in principle, just ssh /var/servers/gw over NFS!
edit: actually read the proposal and it mentions most of my points, including Syncthing :).
by rwmj on 11/27/23, 1:25 PM
It's pretty useful in test suites where you don't want to open a public TCP port (even on localhost), for obvious security reasons but also because it's hard to pick an unused port without conflicting with other tests running at the same time. Example test using this: https://gitlab.com/nbdkit/nbdkit/-/blob/master/tests/test-cu...
by erinaceousjones on 11/27/23, 1:34 PM
As a workaround, (I believe, though only through a cursory web search and haven't tested) you can use network namespaces and socat to proxy traffic from Unix sockets to a private IP:port range only visible to your user - taking that part of containerization without necessarily having to execute things inside containers.
by p4bl0 on 11/27/23, 1:46 PM
I like the idea of specifying the socket in place of the port number in the URL.
by nine_k on 11/27/23, 2:05 PM
I wonder why an actually secure local connection to a web UI is considered to be of very little benefit. This sounds crazy to me, for all these years.
by philsnow on 11/27/23, 3:19 PM
I haven’t seen this proposal yet in this thread: instead of convincing browser vendors to support connecting to Unix domain sockets, contrive a tiny adapter which listens on a localhost port and expects http with basic auth (and either generates a random username and password or accepts them by environment variables), prints out a url with the password like
Hi! To connect to your service at /tmp/whatever-service.unix, tell your browser to go to
http://fwahjiddbjko:derhhkiytdfbkifdx@localhost:45678/
You could do this with nginx really easily but you’d have to keep track of a config file for each service.
See https://stackoverflow.com/questions/17701420/bypassing-http-... for a similar idea (but that is about stripping auth, not adding it)
by stop50 on 11/27/23, 12:37 PM
by metafunctor on 11/27/23, 2:06 PM
Unix domain sockets are great. I find it completely amazing that they are not used more widely.
Since when was it OK to open a TCP listener when you don't want to receive connections over the network? Did everyone forget about that during their Kuberenetes fling, am I too old, or what?
by paroneayea on 11/27/23, 2:46 PM
For a great example of this, see how Guile's live REPL was localhost + port... cool, only local users could access it, right? Except browsers could access localhost + port, and it turned out this was a path to being able to do arbitrary code execution in the browser https://lists.gnu.org/archive/html/guile-user/2016-10/msg000...
Switching to unix domain sockets was the recommended path, and that's only because browsers don't support them.
If you want to support unix domain sockets, you could, but it would have to be via object capability security discipline, and the poster explicitly talks about an ACL "protecting" things... it wouldn't.
Luckily this is 3 years old and hopefully will never make progress.
by aldonius on 11/27/23, 1:38 PM
by andix on 11/27/23, 3:20 PM
For web based desktop applications this might be a good solution. But there it is usually done with custom IPC. I think Electron can do it with custom protocols.
Listening on localhost is usually not a great solution. It's impossible to do HTTPS right this way (without HTTPS there is a danger of a MITM attack from an unprivileged process). Also authentication is an issue then, without authentication there is a possibility of an privilege escalation.
by josephcsible on 11/27/23, 3:23 PM
This can't be said enough times. Browser vendors should never, ever say "we're not supporting feature X because it's not popular enough, and other browsers don't support it" when lack of browser support is what's keeping it from getting popular. We'd literally never get any new features if they always used that logic.
by claudex on 11/27/23, 1:39 PM
by mildmotive on 11/27/23, 4:20 PM
by est on 11/27/23, 1:33 PM
by H4ZB7 on 11/27/23, 2:43 PM
i want out of this community. all these little people who have zero contextual understanding always requesting and implementing these features at all costs as long as the idea exists. this is a un*x problem at the core: if a feature conceptually exists, we must implement it at all costs. and another un*x problem here is having a global namespace (tcp port numbers) that things are just exposed to everything (either localhost or the network) by default when they could have easily just used an opaqaue handle that the machine operator can copy and paste into whatever application he wants to use it (no some openauth type shit that failed to be secure for 15 years is not what i have in mind)
by peterhull90 on 11/27/23, 2:43 PM
[0]: https://gs.statcounter.com/os-market-share/desktop/worldwide...