On Di, 2016-05-31 at 11:56 +0200, Lennart Poettering wrote:
On Tue, 31.05.16 11:31, Gerd Hoffmann (kraxel(a)redhat.com) wrote:
> IMO systemd should allow to specify the KillUserProcesses policy
> separately for processes with/without controlling terminal. So you
> could ask systemd to zap any gnome process going wild on logout without
> breaking screen and tmux.
Again, as mentioned before: key here is that permitting user processes
to stick around after all sessions of the user ended needs to be a
It should not be allowed for user code to stick
around after logout, unless this is explicitly permitted by the admin,
Having a switch for that so the admin can permit or deny this is fine.
Having it default to "deny" is rude IMO.
Traditionally this has worked and there are some very reasonable use
cases for this. logouts are not always intentional. If some internet
hickup breaks your ssh connection you are logged out too, and the usual
way to avoid your remote session being killed by that event is running
your stuff in screen.
Hence, whether a process reacts to SIGHUP or SIGTERM or not is not
suitable at all as indication on whether to permit them to stay around
or not, because that's something that is exclusively up to the
processes themselves, and requires no privileges at all to make use of.
Its still useful as indication whenever the user wants the processes
stay around or not. So systemd should IMO use it for a more
fine-grained control over the kill behavior.
Maybe turn KillUserProcesses into a tristate: Yes/WithoutTerminal/No.
Maybe make it depend on the "linger" option to avoid a new config
switch. From a security point of view that makes sense, if the admin
allows users to enable lingering for themself they are able to leave
processes running after logout anyway, so systemd could also allow that
using the traditional unix way via SIGHUP handler.