On Di, 2016-05-31 at 11:56 +0200, Lennart Poettering wrote: > On Tue, 31.05.16 11:31, Gerd Hoffmann (kraxel@xxxxxxxxxx) 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 > privilieged concept. Sure. > 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. cheers, Gerd -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
