On Fri, 15.07.16 08:55, Nico Kadel-Garcia (nkadel@xxxxxxxxx) wrote: > On Tue, Jul 12, 2016 at 6:33 AM, Lennart Poettering > <mzerqung@xxxxxxxxxxx> wrote: > > On Sat, 09.07.16 21:20, Nico Kadel-Garcia (nkadel@xxxxxxxxx) 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
