3 ms·

I use nginx for that. I would like to see more software that provides the option to listen to unix sockets. Most still won't work with unix sockets. Some promet

by stop50 3y ago

I use nginx for that. I would like to see more software that provides the option to listen to unix sockets. Most still won't work with unix sockets. Some prometheus exporters at least support systemd socket units.

harvie 3y ago
maybe systemd will come up with some kind of sandboxing that automaticaly converts TCP servers to unix sockets and unix sockets to TCP listeners available only in network namespace of individual users :-D Actualy namespacing syncthing per user might be enough for every user at same system to run syncthing at tcp/8080 or whatever.
- rodlette 3y ago
  Ask and ye shall receive: https://www.freedesktop.org/software/systemd/man/latest/systemd-socket-proxyd.html https://www.freedesktop.org/software/systemd/man/latest/syst... I use it for the usecase you describe.
agwa 3y ago
I wrote an LD_PRELOAD library which can replace binds to a TCP port with binds to a UNIX socket: https://github.com/AGWA/ldpreload#ldpreload-unixbindso https://github.com/AGWA/ldpreload#ldpreload-unixbindso
kevincox 3y ago
NGINX solves half of the problem. It allows accessing UNIX socket services over TCP. This is great and I do it wherever possible (mostly because I can add my own access control and everything has to go through it, even local processes). But it doesn't allow local access without going over TCP. So for example if CUPS or Syncthing listened on a UNIX socket you can use NGINX to expose this over TCP, but now you are back at the original problem of any local process can access this service and you need to worry about port conflicts. You can work around this by adding access control but this doesn't elegantly solve the core problem. So it is valuable to have a client (like Firefox) that can directly access the socket. This way you get native UNIX permissions and a whole filesystem namespace to prevent conflicts.
vamega 3y ago
Another LD_PRELOAD based solution can be found here: https://github.com/nixcloud/ip2unix https://github.com/nixcloud/ip2unix I use it to run a number of services under systemd, and haven’t had any issues.

by stop50 3y ago

harvie 3y ago

maybe systemd will come up with some kind of sandboxing that automaticaly converts TCP servers to unix sockets and unix sockets to TCP listeners available only in network namespace of individual users :-D Actualy namespacing syncthing per user might be enough for every user at same system to run syncthing at tcp/8080 or whatever.

rodlette 3y ago
Ask and ye shall receive: https://www.freedesktop.org/software/systemd/man/latest/systemd-socket-proxyd.html https://www.freedesktop.org/software/systemd/man/latest/syst... I use it for the usecase you describe.

agwa 3y ago

I wrote an LD_PRELOAD library which can replace binds to a TCP port with binds to a UNIX socket: https://github.com/AGWA/ldpreload#ldpreload-unixbindso https://github.com/AGWA/ldpreload#ldpreload-unixbindso

kevincox 3y ago

NGINX solves half of the problem. It allows accessing UNIX socket services over TCP. This is great and I do it wherever possible (mostly because I can add my own access control and everything has to go through it, even local processes). But it doesn't allow local access without going over TCP. So for example if CUPS or Syncthing listened on a UNIX socket you can use NGINX to expose this over TCP, but now you are back at the original problem of any local process can access this service and you need to worry about port conflicts. You can work around this by adding access control but this doesn't elegantly solve the core problem. So it is valuable to have a client (like Firefox) that can directly access the socket. This way you get native UNIX permissions and a whole filesystem namespace to prevent conflicts.

vamega 3y ago

Another LD_PRELOAD based solution can be found here: https://github.com/nixcloud/ip2unix https://github.com/nixcloud/ip2unix I use it to run a number of services under systemd, and haven’t had any issues.