On Tue, Jul 12, 2016 at 6:33 AM, Lennart Poettering
On Sat, 09.07.16 21:20, Nico Kadel-Garcia (nkadel(a)gmail.com) wrote:
> > In either case it will be up to FESCO to decide and set guidelines on
> > implementation and for us grognards to either deal with the change or
> > go find an OS we can be happier in.
> It looks to me like the critical change to even consider activating
> this dangerous policy is to *log* the killing of userland processed.
> Date, euid, guid, and pid are a minimum: the name of the process would
> be even better, and the contents of the process invocation command
> line would be even more useful.
> Can systemd even gracefully poll for that information at the time of
> killing these processes? Or would systemd developers feel a need to
> re-invent "ps" from scratch to report this?
I figure it would be OK to add code to systemd that logs about all
processes we kill with SIGKILL and all processes we kill after a
"scope" unit is "abandoned".
I'm glad you've commented on the thread. I admit that I was personally
surprised to find that such a feature had been activated without
Would it be reasonable or feasible to activate a "WARNING" level for
UserKillProcess, similar to that used by SELinux? For an admin
considering this feature, it could be invaluable to generate a day or
week of logs about which processes *wouild* have been killed. I'm
particularly thinking of some hand-run backup tools used by former
colleagues, tools that used all manner of MySQL, Postgresql, rsync,
dump, tar, and scattered backup tools run manually as opportunities
(Regarding the terms used above: In systemd "scope" units
concept how groups of processes not started by PID 1 are maintained,
very similar to a "service" unit, the only difference being that
"services" are forked off by PID 1 itself, while "scopes" are
by other code. Login sessions are maintained in "scopes" as it is not
systemd that starts their processes but getty/gdm/... And "abandoning"
a "scope" is what happens when the process that created the "scope"
goes away before the "scope" itself goes away. This is what happens to
the login "scopes" as soon as gdm/getty/... consider the session
I think logging about all processes we send signals to (i.e. SIGTERM)
would be too much, as this pretty typically happens all the time, for
example when a service is terminated. Logging about SIGKILL and
From your explanation, I think you're correct. I'll note that
reporting "SIGTERM" operations might be useful as an admin selectable
debugging uption, I don't have a good sense of how much it would spew
into the logs. Might it be useful as a debugging option? Do you need
or want a feature request for that?
abandoned scope process is different however, as in that case the
processes conceptually are "left over", as the clean shutdown logic
(which is SIGTERM, or the scope's owner shutting it down propery)
apparently didn't work.
Please note that my personal concern is processes for which logging
out or losing a login connection *should not* shut down the process.
Whitelisting them seems infeasible, and modigying them all to work
well with KillUserProcess quickly becomes a herculean task. Just
thinking of my work in the last few years, they include "dd",
"tar", "mysql" and its related commands, "psql" and its
commands, "gzip" and all its variants, "xz" and all its variants,
"bzip2" and all its variants", "mock", "koji", and
Lst: I'm afraid the list also includes the wrapper "nohup", which many
of us use to log long-running tasks. It's especially useful when we
don't want to incur the overhead of using "screen" or "tmux", and
leaving those dangling sessions. And let's be honest: as soon as
"nohup" is effectively whitelisted. the game is pretty much over. The
most system abusive processes, exactly those for which KillUserProcess
is most effective, can typically be wrapped with nohup.
> Lennart Poettering, Red Hat
> devel mailing list