Default services enabled

[Lennart Poettering]

On Wed, 24.08.11 00:24, Björn Persson (bjorn at rombobjörn.se) wrote:

> Mathieu Bridon wrote:
> > Well, socket activation gives you better speed and resource usage as
> > already mentioned, but it also gives you:
> > 
> [some really nifty features]
> > 
> > So basically, much improved service availability (which is what matters
> > to your business, isn't it?), and easier configuration/maintenance
> > (granted, once you've learnt the new commands/tricks).
> > 
> > Knowing that the security issue is highly exaggerated (as Lennart has
> > repeatedly stated, systemd doesn't read network packets), does that seem
> > like a better trade-off?
> 
> It might be an acceptable trade-off but I'm not yet convinced that such a 
> trade-off is necessary. Is it really impossible to have both a simple, network-
> unaware Init and all the nifty features of SystemD?
> 
> Imagine a stripped-down Init that does only two things: First it forks and 
> executes SystemD, and then it just sits around and reaps orphan zombies. 
> SystemD would then run as process 2 and do all its socket activation and other 
> magic from there. Process 1 would then be immune to network-based attacks, and 
> it would be possible to kill SystemD if desired (although it would surely 
> leave the system rather handicapped).
> 
> The only thing I can think of that would be a problem is if SystemD needs to 
> be notified when processes die even when those processes aren't children of 
> SystemD. Is that the case? Is there anything else that only process 1 can do?

systemd is actually nicely stripped down. I am not sure what people
think that is so bloated in PID 1? Is this hate for D-Bus, what is it?

I am pretty sure systemd will win any competition in size and resource
usage when you compare a systemd system with one built of a number of
similar components, which offer the same functionality. And why is that
so? Since it's lean C, and since it reuses common code as much as
possible. If you have your bazaar of basic building blocks like we used
to have it on Linux then the simple fact is that a big chunk of that
code is just the same stuff implemented over and over again. You have
the daemonization stuff, you have the process supervision, you have
local IPC systems, for each and every component reimplemented again and
again. And all these reimplementations have in common that they suck and
are limited, and do not even remotely compare to the feature set that
systemd offers you in trivially easy to use settings. (I mean, come on,
PrivateNetwork=yes, you must love that, can't you guys admit that?)

You know, there's a reason why systemd is popular for all kinds of
embedded setups, why it is being used in mobile devices, on MeeGo, in
cars, in children's toys, in household machines and all the other stuff:
because it minimizes the stuff you need to build a system and reduces
duplication, and guarantees robustness that was previously not
available. I mean, seriously, we can run syslog now in a way that it can
crash and can be restarted without losing a single packet, and all that
fully in parallel getting rid of all dependencies and stuff. How awesome
is that? Can you really see no benefit in all of this?

I really honestly wished the troupe of you four or five people who keep
trying to noisily shoot systemd down on fedora-devel would actually try
to understand what is going on. Try to get the bigger picture. Try for
once to see if there might be something good in systemd, because there's
a lot.

People tend to be opposed to change, unless the change happens in there
very own interest area. I can understand that you are not interested in
having the init system change, that you know sysvinit and never felt the
need to change it. But please, you need to to understand that this is a
very limited view of the world. Progress needs to take place, if there
are good reasons for it -- and we have plenty good reasons! If we stay
stuck in 80's Unix then we'll not be able to compete, because nobody
will be waiting for us. Nobody will. The OS market is moving fast, and
so must we.

Seriously guys, embrace progress, and help us getting things right. Just
sitting there on the mailing list, and complaining when it already is
too late anyway and the train already left the station is just not
helpful, and makes the lifes of those who care, who do the improvement
work hard.

It is easy to develop a negative opinion, but I kinda get the feeling
that up to 85% of all criticism I get on this unfriendly place that is
fedora-devel is simply because the people complaining didn't bother to
read the docs, ask around, or even use google.

So guys, be more positive. Everybody can be a complain sometimes, but
complaining all the time will make people not care for you anymore and
will make people just shut off and ignore you. And hell yeah, I am
this > < close to it.

I am sure you can come with a ton of theoretical attacks on systemd, if
you think that calling socket() from PID 1 is indeed the worst thing a
program can do on this world. You'll probably be very much alone (or
well, you'll probably be joined by the rest of your troupe) in your
paranoia however, and if invoking socket() was really that dangerous it
probably should be fixed in the kernel. OTOH, if you tried to be
positive you could also remove your tunnel vision on theoretic (and in
reality non-existing) problems and see the security benefits systemd
gives you. We provide packagers, developers, administrators with very
very easy hooks to make their services secure (I will blog about this),
and we give you all controls to limit resources in almost every possible
way in order to avoid DoS, we allow you to flexible jail your services
in namespaces. We do this making use of capabilities, namespaces,
certain cgroup controllers. We also guarantee execution of all services
in pristine execution contexts whith no leaking execution data, and do a
ton of other stuff to make things easily securable. And that is an
absolute first on Linux, heck even on Unix. I am pretty sure at least
that systemd is the first and still only init system that provides you
with options like CapabilityBoundingSet= or PrivateNetwork= or
ReadOnlyDirectories=. Can you name me even one init system empowering
you with powerful (and simple!) tools like this to secure execution of
services? Upstart doesn't, sysvinit doesn't, SMF doesn't, launchd
doesn't. I am listening!

So, if you guys keep repeating that systemd was bloated or insecure then
I'll just ignore you because the truth lies very differently: a real
systemd system will be smaller and more secure than a sysvinit system.

Thank you,

Lennart

-- 
Lennart Poettering - Red Hat, Inc.