Hi, Lennart Poettering wrote on Wed, Jun 01, 2016 at 03:48:04PM +0200: > 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. 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 something too. All is left is single user workstations that may be happy with the new default value, but my personal narrow-minded opinion thinks that represents less... 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 use. 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 downstream... - 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 screen) 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 keeps running.) - 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. -- Dominique -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
