On Fri, 12 Apr 2019 11:21:13 +0200
Lennart Poettering <mzerqung(a)0pointer.de> wrote:
On Do, 11.04.19 17:08, Przemek Klosowski
> > The logic in systemd is more strict on putting boundaries on
> > resource usage, and thus will by default not allow you to consume
> > resources while you are not logged in. It's really how this
> > always should have been designed. However, we fully acknowledge
> > that there are many uses where the ability to run stuff
> > independently of any login as your own user is fine, but you need
> > to turn on lingering for that (which is privileged), so that this
> > is explicitly marked OK.
> It IS very useful for systemctl to prevent resource leaks by
> killing errant processes (hanging browser, etc)---however, as we
> discussed, some processes should not be killed; I know which
> processes I want to annoint this way, and I take responsibility for
> their possible misbehavior.
> I understand that set-linger disables process harvesting for all
> processes in the session, though, and I would like to just do it
> only for SOME processes.
If you enable lingering for a user, it's the "systemd --user" instance
(i.e. the per-user service manager) that is started at boot and
terminated at shutdown (instead of started at first login and
terminated at last logout of the user), that's all.
If you then run code as user service (i.e. as a service started and
managed by the "systemd --user" instance instead of PID 1) then it is
lifecycled (and its processes killed as needed) by the user service
manager. And you can configure the way you want killing to behave like
you would for any systemd service: with KillMode= in the unit file.
This doesn't really fit with the security requirements we need.
Anything run outside of a user session needs to have an audit session id
and login uid assigned to anything run. We also need to have the
ability to know the name of the script that is being run in an audit