On 06/01/2016 09:48 AM, Lennart Poettering wrote:
On Wed, 01.06.16 12:19, Howard Chu (hyc(a)symas.com) wrote:
> This is still looking at the problem back-asswards. The problem isn't that
> screen and tmux are special cases. The problem is that some handful of
> programs that got spawned in a GUI desktop environment are special cases,
> not exiting when they should.
> Fix the broken programs, don't force every well-behaved program in the
> universe to change to accommodate your broken GUI environment. This is
> Programming 101.
Again, this isn't just work-arounds around broken programs. It's a
security thing. It's privileged code (logind, PID 1) that enforces a
clear life-cycle on unprivileged programs.
Any scheme that relies on unprivileged programs "being nice" doesn't
fix the inherent security problem: after logout a user should not be
able consume further runtime resources on the system, regardless if he
does that because of a bug or on purpose.
As presently designed, it's a
usability problem because it collides with
the often-required idle session timeout. Your desktop session will stay
up, but any remote connections subject to idle timeout will kill
long-running jobs on logout. Since in general we can't predict how long
the command will take (especially the system administration commands),
we will have to use the convoluted invocation to persist the jobs across
the unpredictable idle logout, or disable the feature.
It's ironic because as you point out it's a security risk to leave those
processes running, and yet the sensitive systems are more likely to have
the idle timeout turned on.