On 06/03/2016 01:33 AM, Andrew
Lutomirski wrote:
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. |
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx