On May 31, 2016 3:24 PM, "Howard Chu" <firstname.lastname@example.org> wrote:
> DJ Delorie wrote:
>> Lennart Poettering <email@example.com> writes:
>>> Again, as mentioned before: key here is that permitting user processes
>>> to stick around after all sessions of the user ended needs to be a
>>> privilieged concept. It should not be allowed for user code to stick
>>> around after logout, unless this is explicitly permitted by the admin,
>>> and this hence needs to be enforced by privileged code.
>> How many Fedora installs are multi-user these days? How many
>> single-user desktops are we afflicting with a "you must ask an admin"
>> rule, when there is no admin besides the user sitting at the keyboard?
>> Any rule that tries to split users into "unpriviledged" and "admin" is
> Agreed. And the basic premise is utterly wrong. The user was obviously permitted to login to the machine, they are therefore permitted to run processes on the machine. Whether their shell process stays alive or not is utterly irrelevant, any other processes that continue to run after their login shell terminates is still legitimately using the machine. To call running without a control terminal "privileged" is inventing new definitions out of thin air. There is no logical basis for it. The entire premise is invalid.
Sure it is. An admin might reasonable want users who aren't logged in not to have processed running. So there are really two issues here:
1. What's a reasonable default? I would venture that allowing processes to persist is the right default. (Current Fedora 24 appears to be set up like that, although the behavior is awkward.)
2. Assuming that users are allowed to have persistent processes, how do they make them persistent? I would argue that the current approach of twiddling both loginctl (via polkit) *and* using systemd-run (currently buggy) is too complicated and is a poor API / user experience.