[systemd-devel] RFC: Setting TasksMax= by default

[Lennart Poettering]

Heya!

So, I am tempted to make the following changes to systemd, and was
wondering about opinions about it:

a) The first change is rather uncontroversial I presume: I'd like to
   set DefaultTasksAccounting=yes in system.conf by default. This
   means we get accounting of the number of tasks per unit enabled by
   default. Effectively this turns on the "pids" cgroup controller for
   all units. According to the cgroups folks this is OK as this
   specific controller is not particularly costly. This means that by
   default "systemctl status" will show a "Tasks: " line then, showing
   the number of tasks in the service. cgtop will be more efficient,
   too, then.

b) I'd like to introduce DefaultTasksMax= that controls the default
   value of the per-unit TasksMax= by default, and would like it to
   set to some value such 1024 out-of-the-box. This will mean that any
   service or scope created will by default be limited to 1024
   tasks. This of course is a change from before that has the
   potential to break some daemons that maintain an excessive number
   of processes or threads. However, I think it's a much better choice
   to raise the limit for them, rather than stay unlimited for all
   services by default. I think 1024 is not particularly low, but also
   not particularly high. Note that the kernel by default limits the
   number of processes to 32K in total anyway.

c) In logind.conf I intend to add a TasksMax= setting that sets the
   number of tasks for user sessions, and overrides the systemd-wide
   setting for user scopes. It would also be set out-of-the-box, and
   default to something like 8K or so. (Note that this is very similar
   to setting RLIMIT_NPROC via /etc/security/limits.conf, but has the
   benefit of covering also suid binaries, being nicely queriable
   via systemctl status and controllable during runtime via "systemctl
   set-property" and so on)

d) in systemd's own unit files we'll configure much lower settings by
   default, since we know how many tasks they require.

All this together should improve security as it provides a certain
amount of per-service protection against fork bombs and suchlike. A
single service cannot fork boundlessly anymore, and that's not
something services would have to explicitly implement as before, but
that would just be there out-of-the-box.

Of course, it also has potential to break some services, but I think
defaults like 1K and 8K are high enough to make this the exception,
not the rule. In summary, I think we gain more by improving security
and robustness through putting strict limits on everything we do, than
we lose.

Users could of course unset these defaults, to lift the limits. And
packages could lift the limit in their unit files too, if they know
that they are too low for their specific service.

Any opinions?

Lennart

-- 
Lennart Poettering, Red Hat