Support listening on UNIX sockets

[mradermaxlol]

Is your feature request related to a problem? Please describe.

I would like to have as many web services on my machine as possible use UNIX sockets instead of i.e. localhost:port combinations. Currently, Navidrome doesn't support listening on sockets (or at least it is not stated in the documentation of the project).

UNIX sockets are of little use if one has Navidrome as the only running web app on the system (e.g. you cannot directly access your web services running on sockets from a browser); however, sockets are great when one has multiple web services running on localhost and serves them with nginx and co. proxy_pass'ing sockets is more secure and efficient, and it also makes the network setup a lot less complicated by eliminating those localhost:port listening addresses.

Describe the solution you'd like

So here it is, the request to support listening on sockets! The configfile could be expanded with directives like "ListenType="socket|address", with address and port settings ignored when using sockets, and SocketPath="/path/to/socket".

[deluan]

How would you access the service over Unix socket? Which client supports it? And how would you access it from a browser?

[mradermaxlol]

I use nginx for reverse-proxying various web services and serving static stuff, so I basically proxy_pass the socket file to the location accessible by the IP address/domain name. I hope this answers your questions :)

[epoupon]

You can setup permissions on unix sockets, so this is basically a request to improve local security (prevent other processes from accessing navidrome)

[mradermaxlol]

You can setup permissions on unix sockets

Yep, this one's a nice side effect of using sockets. It basically boils down to greater performance and security + less complexity (less actual addresses to listen on).

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. The resources of the Navidrome team are limited, and so we are asking for your help.
If this is a bug and you can still reproduce this error on the master branch, please reply with all of the information you have about it in order to keep the issue open.
If this is a feature request, and you feel that it is still relevant and valuable, please tell us why.
This issue will automatically be closed in the near future if no further activity occurs. Thank you for all your contributions.

[mradermaxlol]

@deluan sorry for the bump, but maybe you could take a look at this FR once again as it looks like you're fiddling with the server part now? :)

[deluan]

Hey @mradermaxlol , please let me know if this works. You'll need to specify the config option Address as unix:/path/to/socket/file

[deluan]

Question: Should we set the permissions of the socket file in Navidrome, or let the umask take car of that? If we should, what would be a sensible value? 0660? 0600? Not sure if it is worthy to make it configurable.

[kevincox]

My recommendation is to support socket passing. This was a service manager can pass you the socket. The common ways are inetd and systemd style. Since I don't see a use case for multiple sockets we can probably just do inetd style which passes the socket as the process's stdin. This way navidrome doesn't need to grow a plethora of socket configuration options for every niche use case and can rely on the service manager (or any other caller) to pass the socket pre-configured. This also has a number of benefits such as hitless restarts, ability to bind privileged ports without running as root and placing unix sockets in otherwise unwritable directories.

[deluan]

I'll leave it like that for now, but I'm experimenting with socket activation as @kevincox suggested and may improve in a future release.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.