Default services enabled

[Miloslav Trmač]

On Wed, Aug 24, 2011 at 1:03 AM, Lennart Poettering
<mzerqung at 0pointer.de> wrote:
> On Wed, 24.08.11 00:24, Björn Persson (bjorn at rombobjörn.se) wrote:
>> 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?
* From the UI perspective, systemd _is_ bloated.  The "UI surface" of
systemd is really large, and it's getting larger all the time.  The
amount of components that the admin now sees in the same place as the
most important httpd server has what, quadrupled?
* From the design perspective, it's, compared to UNIX tradition, a
very extensive single component (even ignoring /lib/systemd/*) that's
difficult to take advantage of in pieces.
* From the attack surface perspective, systemd does increase it.
* As for moving things out of PID 1, that looks plausible from the
outside - although restarting the "PID 2" would likely be difficult
and unreliable, and perhaps not worth it, but some things really don't
have to be in there, see below.
* As for D-Bus... I'm not a fan of having its own implementation of
"glib-lite", but *shrug*

> 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.
That's not the relevant question.  Just because systemd provides a
feature doesn't mean that others have to do it as well in order to be
worthy of being included in the comparison.

> 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.
Right, but _all of these implementations in these daemons still exist
after you add systemd_. So the total amount of code, total attack
surface, total complexity of the system is larger with systemd.

> 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?)
Why?  There already is unshare(1) - or even systemd-nspawn.  Why is it
so necessary to provide this functionality
1) in PID 1
2) in the main daemon process of systemd (which, as argued by Björn,
perhaps shouldn't be PID 1)
3) and, ultimately, in the same software package as PID 1?

> You know, there's a reason why systemd is
<advertisement>
> Can you really see no benefit in all of this?
Can you really see no cost and complexity in all of this?  As one who
has spent a few months trying to get /etc/init.d/* reliable, I'm all
for eliminating PID files and so on, and systemd provides that - only
if I accept the rest, which is not always so appealing.

> 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.
And if we run away from our users, we'll not be able to compete
because we won't be on their map :)

> 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,
*shrug* Apparently complaining 17 months ago was not helpful either...

> 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!
This is supposed to be attractive, but it is really borders on scary.
To use the same kind of exaggerating presentation, systemd is already
more than three times as large as the UNIX v7 kernel!  libpam is
included only for PAMName= - and Google can find only two mentions of
PAMName outside of this mailing list, and no distribution or project
using it.  I do hope the features advertised above are different.

Why does the focus seem to be on packing as many features into systemd
as possible, instead of any of:
* compatibility in the boring details (such as SysV service ordering)
* completeness of transition (e.g. having packaging ready guidelines
_before_ GA)
* seamlessness of transition (replacing things one at a time, keeping
100% compatibility)
* user friendlines (providing sysadmins an UI that treats a single
"server" as a single unit instead of several), or perhaps
* reusability (making the service execution facility available _to_
things such as cron and PAM)
? At least to me, anything of the above would be more appealing than
the dash to pack as many things into systemd.exec as possible.

> 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.
I really look forward to seeing you prepare, submit upstream _and_ get
accepted patches that remove the existing duplicate implementations,
then.  That's the difficult part.
   Mirek