On Fri, 15.07.16 08:55, Nico Kadel-Garcia (nkadel(a)gmail.com) wrote:
On Tue, Jul 12, 2016 at 6:33 AM, Lennart Poettering
<mzerqung(a)0pointer.de> wrote:
> 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
logging.
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
occurred.
We can meet in the middle and make this LOG_NOTICE. That's not the
usual LOG_INFO, but also not the higher LOG_WARNING.
Lennart
--
Lennart Poettering, Red Hat