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. > (Regarding the terms used above: In systemd "scope" units are a > 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 started > 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 > having ended.) > > 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", "rsync", "tar", "mysql" and its related commands, "psql" and its related commands, "gzip" and all its variants, "xz" and all its variants, "bzip2" and all its variants", "mock", "koji", and "make". 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 of 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 > > -- > Lennart Poettering, Red Hat > -- > devel mailing list > devel@xxxxxxxxxxxxxxxxxxxxxxx > https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
