On Fri, 12 Apr 2019 11:21:13 +0200 Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote: > On Do, 11.04.19 17:08, Przemek Klosowski (przemek.klosowski@xxxxxxxx) > wrote: > > > > 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 event. -Steve _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
