Lennart Poettering wrote on Wed, Jun 01, 2016 at 03:48:04PM +0200:
Again, this isn't just work-arounds around broken programs.
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.
I actually don't understand this as being security, at least with the
current default values where a user can set lingering for themselves and
run explicitely separate sessions; anything they could do can still be
done and it's just more work.
If a sysadmin wants to "secure" their environment (and it definitely
does make sense in some use cases, like shared stations), they will also
want to disable lingering, so they'll need to change something anyway to
disable that possibility; so the default doesn't suit them.
If a sysadmin wants their users to be "least surprised", they will very
probably want to change the new default back off, so they need to do
All is left is single user workstations that may be happy with the
new default value, but my personal narrow-minded opinion thinks that
While I'm actually writing a mail I might address a few more points:
- I definitely have more programs than just screen & tmux I want to
keep running, although most could be started with nohup/systemd-run, I
usually don't bother (&/^Z, bg and disown is how I usually do it
afterwards if I notice)
- Only screen/tmux come back all the time, but there are other
alternatives - neercs, dtach to name two I know by name and occasionally
I'm sure there are more. I'm not sure they will all want to adapt, like
tmux that seems to refuse right now, and it will be a pain to manage
- I'll agree I mostly lock my screen on my own station if I want things
to keep running, there however are particular cases where I need to
close firefox/crap running and I will logout to close the X cruft;
I'd still expect things like my fetchmail loop to run then (it's in a
This mainly happens on friday afternoons when I have mettings in another
building and will log in from a shared post there, and the home
directory is shared so my main station needs some cleanup (and logging
out cleans all I want cleaned right now, but it doesn't have the new
user session dbus system yet... Although I guess I don't care if that
- FWIW, I'm also of the opinion there are less non-X things that I want
killed than things I want to stay (assuming things connected to X will
die anyway when the session closes); so if we're going through the
trouble to make an interface so programs can explicitely ask to not be
killed, I don't see why these programs that we want killed (the user
dbus, pulse, gnome calendar) could not just voluntarily ask "please kill
me when the session is closed".
I think both solutions make sense, and if we want to allow both usages
doing both might actually be the way forward that will please both side:
admins can chose which camp they're in through a simple switch AND their
relogging is not broken in either case.