On May 31, 2016 3:24 PM, "Howard Chu" <hyc(a)symas.com> wrote:
DJ Delorie wrote:
> Lennart Poettering <mzerqung(a)0pointer.de> 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
Agreed. And the basic premise is utterly wrong. The user was obviously
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.