On Wed, Jun 1, 2016 at 9:48 AM, Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote: > On Wed, 01.06.16 12:19, Howard Chu (hyc@xxxxxxxxx) 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. Correct, but it's a new lifecycle that currently doesn't exist. Traditional PID 1 was essentially "start things I'm told to start, reap children that are zombied to me." Systemd has obviously improved that in various ways, and this functionality can be seen as another such improvement but it is not a clear-cut, easy decision. > 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. You keep saying this, and logically that makes sense. However, that is essentially putting blinders on to how Linux systems have worked and have been used for a very long time. The functionality you are describing should exist because it does solve a problem. The issue is what to do by default. Given the principle of least surprise, it would make more sense to default with this being disabled out of the box. People leave tasks running in the background in various ways all the time for a variety of valid reasons. Builds, IRC sessions running in screen/tmux, local server processes, etc. That default could be set in Fedora itself if upstream systemd wants to default with it on. Or it could even vary between Workstation, Server, and Cloud (though I'd argue that doesn't make sense). josh -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
