On Fri, Jul 15, 2016 at 12:34 PM, Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote: > 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 Just to verify: I assume you mean that the killing of these processes would normally emit a "LOG_NOTICE". message. This makes me happier because it produces *some* kind of log. It's pretty scary to just kill user processes with no long whatsoever: this is a positive step. Also to be clear: What about having an alternative "WARNING" setting for UserKillProcess, one that would generate a log message but not actually kill processes? That would help developers and admins to run test systems for some reasonable time, such as a week or so, to audit for processes that people leave dangling and for which the rocesses need modification for compatibily with UserKillProcess. It could also be invaluable for admins faced with software, like "tux", for which the upstream authors seem unwilling to provide compatibility with UserKillProcess, but which an admin may nevertheless want to collect a daily or weekly report of dangling sessions. It's been pesky to write the necessary cron jobs to generate such reports. I'd be delighted to have these dangling processes listed, without actually killing them automatically. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
