Skip to content

Add Unix socket listener support - #149

Merged
ltratt merged 1 commit into
softdevteam:masterfrom
apeschar:unix-socket-listener
Jul 30, 2026
Merged

Add Unix socket listener support#149
ltratt merged 1 commit into
softdevteam:masterfrom
apeschar:unix-socket-listener

Conversation

@apeschar

Copy link
Copy Markdown
Contributor

Allow listen to accept an absolute Unix-domain socket path in addition to an IPv4 or IPv6 socket address.

This adds a shared listener/stream abstraction while preserving the existing HTTP request handling, authentication, and TCP behavior. It also documents the new configuration and adds an end-to-end Unix socket test.

Example:

listen = "/run/snare.sock";

Unix socket paths must not already exist when snare starts.

Tests:

  • cargo test --all-features
  • cargo clippy --bin snare --all-features -- -D warnings

@ltratt

ltratt commented Jul 24, 2026

Copy link
Copy Markdown
Member

Dumb question: what's the use case for listening on a Unix socket vs. a TCP/HTTP socket?

@apeschar

Copy link
Copy Markdown
Contributor Author

Dumb question: what's the use case for listening on a Unix socket vs. a TCP/HTTP socket?

I generally prefer to host internal services on Unix sockets.

  • Unix socket paths are more legible than port numbers. /run/snare.sock vs 18239. You don't have to worry about port conflicts.
  • You can manage multiple configs (eg, for multiple users) without having to allocate port numbers. You can just listen on ~/run/snare.sock, let's say.
  • You can control permissions granularly, eg, only allow nginx to connect instead of every user on the host. Unix sockets follow filesystem permissions. Otherwise restricting local connections requires complicated iptables rules.

@ltratt

ltratt commented Jul 24, 2026

Copy link
Copy Markdown
Member

Most OSs can restrict TCP sockets to a given user. That said, I am inclined to see this as a useful feature. Integrating it sensibly might take a bit of finessing. For example, listen no longer has an unambiguous syntax. A first thought is that socket paths would be of the form unix:/path/to/sock and TCP sockets would -- for backwards compatibility -- be either IP:port or tcp:IP:port. [One day we could deprecate the non tcp prefix.] Warning: I haven't thought this through very carefully yet.

@apeschar

Copy link
Copy Markdown
Contributor Author

listen = IP:PORT and listen = unix:/path/to/socket syntax would match Nginx. I think that's an intuitive approach.

I've updated the PR accordingly.

@ltratt

ltratt commented Jul 29, 2026

Copy link
Copy Markdown
Member

Thanks. I agree with this: please squash and then I can merge.

@apeschar
apeschar force-pushed the unix-socket-listener branch from 2fa7c8b to 074538b Compare July 30, 2026 07:18
@apeschar

Copy link
Copy Markdown
Contributor Author

Done.

@ltratt

ltratt commented Jul 30, 2026

Copy link
Copy Markdown
Member

Thanks!

@ltratt
ltratt added this pull request to the merge queue Jul 30, 2026
@github-merge-queue
github-merge-queue Bot removed this pull request from the merge queue due to failed status checks Jul 30, 2026
@ltratt

ltratt commented Jul 30, 2026

Copy link
Copy Markdown
Member

Ah, that's an unrelated failure. I'll fix in a separate PR and then rerun this one.

@ltratt
ltratt added this pull request to the merge queue Jul 30, 2026
Merged via the queue into softdevteam:master with commit 6d86d72 Jul 30, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants