On Sat, 20.08.11 09:41, Steve Grubb (sgrubb@xxxxxxxxxx) wrote: > > On Friday, August 19, 2011 10:50:01 PM Kevin Kofler wrote: > > Tim Waugh wrote: > > > Oh, I just noticed this: > > > > > > https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd#Socket_activa > > > tion "Since Fedora currently doesn't want any services to do on-demand > > > loading, all socket activated services must autostart." > > > > What the heck?! We're disabling systemd's main feature there, aren't we? > > Wasn't the main design concept behind systemd the observation that > > everything can be parallelized most effectively by on-demand activation? > > Why is bootup speed so important that init now has become network aware? Process 1 > gets special protection from the kernel. You cannot kill it. If there is any mistake > in its code, then you have an unkillable all powerful process that might do rogue > things. It almost sounds like this is reinventing Xinetd - except its not as feature > rich as xinetd. systemd never reads a single packet from any of the network sockets it listens on on behalf of services. It just passes these sockets off to the services as soon as traffic is seen on them (i.e. when POLLIN is triggered we pass off the socket, we don't call read() on it.) > We had a lot of problems with xinetd over the years. For example, if it listens for a > connection that the service must accept and then the service fails before it can call > accept, xinetd will spin in a tight loop because the the listen socket is readable and > the service is not calling accept. systemd (much like sysvinit) rate limits service start-up. If a service respawns too often we will refuse starting it again for a while. > Then lets look at the accept option. If systemd accepts a connection and passes it to > a child process, do you now support tcp_wrappers so that you deny the connection > before starting the child? We do tcpwrap checks for incoming connections. I do wonder though whether it might be time to deprecate tcpwrap distribution-wide. I am pretty sure firewalls are the better approach, more widely supported, more widely understood and more widely used. > That would mean any flaw in tcp_wrappers now is part of process 1 > which has special protection from the kernel. We are very careful with what we execute in PID 1. For example we make sure not to do any NSS lookups or use other code that might pull in arbitrary libraries into PID 1. And following this logic I carefully made sure that tcpwrap checks are not done in PID 1, but in the forked off process shortly before we execute the process binary. And anyway, I wouldn't overestimate the risk here. tcpwrap does not read from the socket, it just executes syscalls like getsockname() and getpeername() and suchlike, but does not parse potentially dangerous network traffic. > How do you limit the number of > children? There's an option for that: MaxConnections=. It defaults to 64. > I personally think systemd's configure should have an --enable-networking. I think this > should be turned off. A network aware init could be internet worm material since you > cannot kill process 1. Please read up on socket activation before making such broad comments. http://0pointer.de/blog/projects/systemd.html Read the part about "Parallelizing Socket Services". It explains why socket actviation is interesting, and why systemd's focus is (much unlike inetd) on AF_UNIX sockets here, not AF_INET sockets. And why the parallelization enables us to do is what matters, and not so much the lazy loading. And again, systemd never reads from the sockets it listens on on behalf of services. It just waits for POLLIN and then passes them off. In fact, the way most modern socket activatable services are written systemd doesn't even call accept() ever, but passes the listening socket off (instead of the connection socket). In this common case tcpwrap isn't invoked by systemd code either. systemd has no network parsing code. And even NSS code (which might potentially parse network packets) is always done out-of-process, never from PID 1. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
