3 ms·

What's old is new again. That's effectively how inetd worked circa 1986. The inetd daemon had some serious security vulnerabilities so the world move away from

What's old is new again. That's effectively how inetd worked circa 1986. The inetd daemon had some serious security vulnerabilities so the world move away from using "socket activated daemons" to having always listening services (performance reasons as well).

thwarted 2y ago
inetd supported "socket activation" using the "wait" directive, where inetd would listen on the socket and then hand off the listening socket when there was activity as fd 0 where the server would need to call accept, and could continue to call accept for new connections, or exit when all clients were handled, and inetd would respawn when there was new pending connection on the listening socket.
rendaw 2y ago
I never understood the use case for socket activation - is someone really running a web server that mixed workloads, long periods with no network traffic you'd rather prioritize something else, and a web server that's so resource intensive when not handling events it makes sense to stop it? Maybe desktop computers? The security aspect is something new to me and I'm not sure if that applies to inetd/systemd socket services or if it's specifically a container thing. Does anyone have more info on use cases for this?
- ratorx 2y ago
  > the security aspect It’s not a systemd-specific thing, but systemd makes it relatively easy to drop privileges (like network in this case), whilst also allowing socket-activated services to be configured easily. You can probably achieve the same thing with inetd + network namespaces (I think this is what systemd uses under the hood)
  - eriksjolund 2y ago
    You can use the podman option `--network=none` together with the systemd directive `RestrictAddressFamilies=` I wrote a demo: https://www.redhat.com/en/blog/podman-systemd-limit-access https://www.redhat.com/en/blog/podman-systemd-limit-access Podman will then not have the privilege to pull the container image, but a web server container can still serve the internet with socket activation.
    - rendaw 2y ago
      What's the use case for that? Multitenant server web hosting where customers provide containers and you want to lock them down I guess? Mostly SaaS/PaaS?
      - eriksjolund 2y ago
        I did it out of pure interest, just to explore ways of locking down a web server.
        rendaw 2y ago
        Oh, fair enough! It is very cool, FWIW.
- piaste 2y ago
  A public facing web server, I doubt it. But for a private one it can make a lot of sense - you are probably only using N services at a time, where N is the number of users. As for what can be so resource intensive that it's worth to wait for startup time instead of running everything at the same time - a bunch of specialized LLMs is the obvious example. Or maybe you're a hobbyist cramming a hundred services into a tiny computer.
- jbverschoor 2y ago
  On-demand applications. But the it should shut itself down after a while too. It’s more useful for applications that keep open a connection for a while instead of stateless request/response architecture

thwarted 2y ago

inetd supported "socket activation" using the "wait" directive, where inetd would listen on the socket and then hand off the listening socket when there was activity as fd 0 where the server would need to call accept, and could continue to call accept for new connections, or exit when all clients were handled, and inetd would respawn when there was new pending connection on the listening socket.

rendaw 2y ago

I never understood the use case for socket activation - is someone really running a web server that mixed workloads, long periods with no network traffic you'd rather prioritize something else, and a web server that's so resource intensive when not handling events it makes sense to stop it? Maybe desktop computers? The security aspect is something new to me and I'm not sure if that applies to inetd/systemd socket services or if it's specifically a container thing. Does anyone have more info on use cases for this?

ratorx 2y ago
> the security aspect It’s not a systemd-specific thing, but systemd makes it relatively easy to drop privileges (like network in this case), whilst also allowing socket-activated services to be configured easily. You can probably achieve the same thing with inetd + network namespaces (I think this is what systemd uses under the hood)
- eriksjolund 2y ago
  You can use the podman option `--network=none` together with the systemd directive `RestrictAddressFamilies=` I wrote a demo: https://www.redhat.com/en/blog/podman-systemd-limit-access https://www.redhat.com/en/blog/podman-systemd-limit-access Podman will then not have the privilege to pull the container image, but a web server container can still serve the internet with socket activation.
  - rendaw 2y ago
    What's the use case for that? Multitenant server web hosting where customers provide containers and you want to lock them down I guess? Mostly SaaS/PaaS?
    - eriksjolund 2y ago
      I did it out of pure interest, just to explore ways of locking down a web server.
      - rendaw 2y ago
        Oh, fair enough! It is very cool, FWIW.
piaste 2y ago
A public facing web server, I doubt it. But for a private one it can make a lot of sense - you are probably only using N services at a time, where N is the number of users. As for what can be so resource intensive that it's worth to wait for startup time instead of running everything at the same time - a bunch of specialized LLMs is the obvious example. Or maybe you're a hobbyist cramming a hundred services into a tiny computer.
jbverschoor 2y ago
On-demand applications. But the it should shut itself down after a while too. It’s more useful for applications that keep open a connection for a while instead of stateless request/response architecture