Default services enabled

[Lennart Poettering]

On Sat, 20.08.11 09:41, Steve Grubb (sgrubb at redhat.com) 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.