Unix Domain Socket

[lukebakken]

Discussed in #7298

^{Originally posted by jvary February 14, 2023}
{repost from rabbitmq-users mailing list}

Hello all!

I am looking to add support for Unix Domain Socket in RabbitMQ, to add extra safety & segregation when used locally (versus listening on 127.0.0.1).
In a 2018 message on the mailing list, it was suggested to do an “exchange plugin“, but since then, ranch_tcp added support for inet:local_address().

My plan would be to change the listeners configuration ‘pipe’ to support inet:local_address() up to ranch, and modify the Erlang & C# client libs to support it as well.

Before I jump into the code, any chance that such PRs could reach the main branch ?

Julien

[lukebakken]

@jvary we'll keep an eye out for a PR. Thanks!

[ansd]

to add extra safety & segregation when used locally

@jvary what does that mean? Can you explain these two terms extra safety and segregation in more detail?
Specifically:

1. Why is it more secure to use Unix domain sockets compared to listening on the loopback address?
2. What means segregation here? What benefits do Unix domain sockets have in this context?

[lhoguin]

1. You can't accidentally expose a Unix domain socket port over the network and can restrict it further via file permissions.

[jvary]

Like Loïc Hoguin said above.

@ansd

Can you explain these two terms extra safety and segregation in more detail?

Mostly any process running on the host can write to 127.0.0.1, and it is easier for mass produced devices to restrict service access by local UserFileSystemPermissions than using ClientSecrets.
Likely the same reasons the ‘Docker daemon socket’ is by default an UnixDomainSocket as well.

Also, we encountered a few funky use cases were we would benefit from a UnixDomainSocket, among them :

• Isolation of a highly exposed process into its own network namespace (Linux; with no 'IP way out' at all from that namespace), but have this process able to output messages to RabbitMQ running in the default namespace.
• Sharing RabbitMQ between the host and ‘network bridged’ Docker containers, without having the RabbitMQ (running on the host) listening on ‘any’ (we would mount the socket in a docker volume)

[michaelklishin]

Thank you for the detailed explanation of your reasoning @jvary

[IniterWorker]

2. The segregation can be achieved by group rights under a Unix operating system or SELinux hardening.
3. The workload on the TCP stack can be reduced by using a Unix socket, which improves resource efficiency, especially in embedded systems with limited resources.

[jvary]

Hello all,

FYI, I did start the work, but while changing the core server-code itself to support UnixDomainSocket wasn't so horrible in itself, I got stuck in updating all the monitoring paths/tools that assumed an IP endpoint.

Given the scale of doing a clean PR that doesn't break the whole ecosystem, it became no longer rational for us to spend so much time on this.

If anyone would like a pet project, here is your chance to take over :-)

[IniterWorker]

Our team has chosen to use RabbitMQ for our embedded system. At some point in our development, I will allow us to work on this issue. If you can share your early work, maybe we can collaborate and share the effort. Thanks, @jvary, for your update.

[michaelklishin]

There are many monitoring-related parts that do assume a (hostname, port) pair. Management UI, Prometheus scraping endpoint and CLI commands such as rabbitmq-diagnostics listeners and derivatives such as rabbitmq-diagnostics report will need to be adjusted.

I don't recall seeing a request for this from paying customers or regular contributors, so until 4.1.x or so, this has a close to zero probability of being worked on by the core team.