Hacker News Reader

Comment by darren0 | Hacker News Reader

The app container specification has socket activation in it. This is going to essentially tie it to systemd. Otherwise you will need another daemon running to do the socket activation, but then that would seem to be a "fundamentally flawed" execution model.

View on HN

Socket activation isn't mandated and completely optional. If an application detects it didn't get its sockets it can certainly just start listening instead if it wishes.

Socket activation does not need systemd in any way. You can launch any socket-activated daemon with https://github.com/LEW21/sdlaunch - without any dependence on systemd.

You may be shocked to discover that socket activation is actually a pretty old idea, and can even be found on non-Linux platforms. systemd embraces it in a pretty big way, but I can't see a problem getting the app containers to work with one of the other socket activation models.

And you may be surprised that I ran socket activation well over 15 years ago, so yes I'm well aware of the approach. The comment is more around the fact that in CoreOS's post they seems to harp on the security of a daemon process running as root that is responsible for spawning containers. What I'm saying is that with socket activation you will essentially have that again. Rocket can only work around it today because they have systemd as PID 1 running as root doing the socket activation.

With capabilities there is no need to have privileges beyond port binding and (possibly) userid assignment, no?

Reply on news.ycombinator.com