On Wed, Jun 01, 2016 at 10:04:27AM -0400, Dan Book wrote:
>
> 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.
>
> Lennart
That's your opinion, and while many sysadmins may share it, many will not.
Having this as an optional security feature would be fantastic. Enforcing
it by default on every user many of which use tmux, screen, nohup, and & to
persist long running processes for daily work, is not something to do just
because you think it is what people should do.
Just a little perspective – this isn't a new option. KillUserProcesses
functionality
seems to be added by
commit 202630822f52e06dce8404633407329c38099278
Date: Mon May 23 23:55:06 2011 +0200
Five years ago, so basically from day one. We have this optional
security feature – fantastic!
Also, the concept of a ”session” isn't anything new, it's core UNIX
concept (setsid() enyone?)
I think that programs needing special treatment should use operating
system's facilities to communicate that. So tmux, screen, nohup should
really open a new session. It's unfortunate that tmux author is hostile
against that, but maybe a clean, compile-time optional patch would persuade
him?
Anyway, I think some examples of ”how to inform systemd I'm a special
program not to reap” would be welcome. Does it need to be done through
D-Bus interaction with logind? Is using PAM sufficient/required?
(Nb. screen already uses PAM for some functionality).
--
Tomasz Torcz There exists no separation between gods and men:
xmpp: zdzichubg(a)chrome.pl one blends softly casual into the other.