On 06/03/2016 01:33 AM, Andrew Lutomirski wrote:

ISTM there are two things that might be reasonably configured:

1. Is a given user permitted to create processes that persist beyond logout?

2. If a user may create processes that persist beyond logout, *which*
processes persist beyond logout?

I would argue that (1) is a reasonable thing for an admin to be able
to configure, but I think it should be configured in one place, not
two.  I would argue that (2) has nothing to do with admin-imposed
policy and is simply a matter of what the *user* wants and should be
done with reasonable APIs.

There's an inconsistency that bothers me in the current proposal: apparently the original motivation was to fix the lockups and delays caused by lingering processes, but it also claims to address the security of processes outside of a login session.

These issues, however, are relevant in different target environments: the process security is important to large, corporate-type multi-user setups, while the delays are important in a single-user personal device context. The corporate context is important, and there should be a way to address it, but I think Fedora should primarily address the personal device context by default, just because that's the primary IT deployment scenario (although maybe RedHat sees it differently).

Andrew is absolutely right that there are two separate issues with lingering: some processes are created to support the session and should be killed with it, but most user processes likely have nothing to do with the session duration---the user started them to accomplish a specific task. Actually, there's yet another case that I think is affected by all this:

3. Processes the user creates outside of the context of login, i.e. personal cron jobs

I use my computer for lots of automation like collecting weather and Pepco powerline data, getting the book of the day, ebay sniping, etc. They all run as either persistent processes or user cron jobs. I am normally logged in, of course, but the current setup works even if I go on vacation and/or the system reboots. I think it would be a mistake to forbid it or even make it difficult to use.

For a user who is permitted to create persistent processes, nohup,
tmux, screen, etc should absolutely create persistent processes.
gconf, ibus, pulseaudio, etc should not.  Presumably, things in
non-default scopes should persist [1], as should explicit services
that aren't configured to automatically shut down.

Anyway, here's an actual idea: could systemd and GNOME arrange for
terminal programs (things invoked in gnome-terminal, via ssh, etc) to
persist and things that are graphical or dbus to not persist?  For
example, GNOME could stick everything into a scope that is killed when
the GNOME session ends, gnome-terminal could split its children into a
different scope, and ssh sessions could have a scope that always
lingers (if permitted)?

This looks promising, but it seems to introduce a mysterious, hard-to-discover duality (some processes get killed and some don't). There should be an easy way to a) specify, b) tell which one is is which, and to discover post-factum why the process was killed.