Distributors ponder a systemd change

> He gets angry about the amount of band-aids he is already carrying around, but this is in many ways the fact that the users already have too many of the old around and can not just fork lift fix their infrastructure at his urging.

The problem is that your "band-aid" is Lennart's security hole. All these band aids are unnecessary code, that is more likely than average to harbour bugs (and hide bugs in the other program too), and are dangerous things to leave lying around. And this example is classic - leaving processes lying around because the system can't/won't get rid of them by default is exactly that! If they're buggy enough not to shut down, how many other bugs do they harbour?

Cheers,
Wol

Even that is too little. You also need to ensure no changes were left that could allow such users to have access to something they shouldn't have -- unless you are actually purging the user from the system ("userdel" style).

I seem to recall a full fix for the "desktop" *security* case requires something like a revoke() syscall, and a proper SAK implementation. I hope I am wrong, because those can be quite hard to implement.

I mean, what is the point of killing every job started in an user session in the name of security, when all the user has to do is to simulate a login screen without ending his session at all in the first place?

There are other ways to ensure no desktop environment components are left behind when the session is closed, especially because these are actually a bounded set *and* because there would be little reason for them to refuse the patches.

You're simplifying the problem. A zombie user process is a threat precisely because no one is actually in control of it making it available for anyone to potentially exploit with the user that started it no longer monitoring it. You don't have to distrust your users for that to be a security issue. I can think of hundreds of ways that could be bad even with a completely trusted user because everyone makes mistakes, zero day exploits exist, and zombie processes are an avenue for all kinds of mischief.

What if you had an orphaned ssl process when the heartbleed vulnerability was disclosed? Even if you patch the binary if you don't shutdown the zombies you just exposed your key to the world. IMO this is a good change to enable default security but I also totally agree that this should have been talked about very publicly that they were going to turn it on with X release. By not doing this they sabotaged their own effort because all the distributions will just disable it and boom it will never get implemented as default. And these programs like tmux and screen whose primary purpose is to daemonize a process (and have been around for more than 30 years) should have not only been warned but the systemd developers should have found a good way to retain that functionality that wouldn't require a dependency (in an upstream that's agnostic to the OS) to fix, even if that is a default exception for those specific binaries.

tldr It's a good change but it was handled terribly.

crontab -e, batch and at are only possible, if the administrator allows for them. The same should hold true for user processes lingering around after the user session is closed.