On 31 May 2016 at 11:10, Hannes Frederic Sowa <hannes@stressinduktion.org> wrote:
On 27.05.2016 15:57, Lennart Poettering wrote:
> On Fri, 27.05.16 08:09, Chris Adams (linux@cmadams.net) wrote:
>
>> Once upon a time, Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> said:
>>> Also note that running jobs in a systemd service has advantages on the
>>> server: better accounting, more transparency, logs are easier to read.
>>> The (old) default of allowing left-over session processes to live on
>>> seems especially bad on a server with multiple users.
>>
>> Starting a one-off task under screen and detaching is an age-old server
>> management process.  Breaking that is not acceptable IMHO.
>
> And it is still supported.
>
> In my view it was actually quite strange of UNIX that it by default
> let arbitrary user code stay around unrestricted after logout. It has
> been discussed for ages now among many OS people, that this should
> possible but certainly not be the default, but nobody dared so far to
> flip the switch to turn it from a default to an option. Not cleaning
> up user sessions after logout is not only ugly and somewhat hackish
> but also a security problem.
>
> systemd 230 now finally flipped the switch and finally by default
> cleans everything up correctly when the user logs out. But we do so in
> a very conservative way actually:
>
>  a) there's a compile time switch to turn this off globally
>     (--without-kill-user-processes, not used in Fedora)
>
>  b) there's a runtime switch to turn this off locally on the system
>     (in logind.conf)
>
>  c) there's a way to opt-out invidually for each user and each task
>     from the cleanup logic, via systemd-run/loginctl linger. This
>     operation goes through PK, and thus can be configured in a more
>     strict or more open policy, depending on whhat the admin prefers.

Would it make sense to add a extended file attribute that allows systemd
to query if an application should be killed or not? screen and tmux
could have those added as long as they don't talk to systemd.

Either this extended attribute could be checked lazily or the elf
process loader could inform systemd about the new requested scope.

Has this been looked at?



So I thought I'd give this a quick go in a rawhide VM for a test, one clone and dnf update later ... 

Indeed you need to loginctl enable-linger <user> before systemd-run --user --scope screen will  persist through a login.

Rawhide currently appears to have selinux issues with initiating the session though as pam_systemd.so activities were being skippe d(so loginctl list-sessions showed no sessions) until the system was flipped to permissive.

With no loginctl enable-linger screen was killed off with both regular screen and via systemd-run

With enable-linger but no systemd-run screen was killed off

With enable-linger and systemd-run screen was persisted

The polkit bit appears broken in rawhide as well since the unprivileged 'localuser' user got:
[localuser@localhost ~]$ loginctl enable-linger localuser 
Could not enable linger: The name org.freedesktop.PolicyKit1 was not provided by any .service files

As root this could be enabled for localuser though


This does seem a fairly invasive change and currently semi-broken for testing in its entirety, can you please change the default in Rawhide to not follow upstream at this time and issue the F25 change for FESCO to decide on?