Distributors ponder a systemd change

Posted Jun 8, 2016 1:06 UTC (Wed) by smoogen (subscriber, #97)
In reply to: Distributors ponder a systemd change by TMM
Parent article: Distributors ponder a systemd change

But does it? You have to block cron, at, system level containers, and all their ilk to actually make sure that a service doesn't fire up after a user logs in. And in the primary work case where you have a user able to log in remotely, they also need to be able to use these sorts of system level services so it doesn't stop their setting up a reverse nc shell or stop someone from piggybacking on the ssh multiplex and making sure the account never truly logs out.

I understand the security item that Lennart sees, but I think that this is a bandaid where the 'fix' he wants will require him to write his own distribution from the 'ground-up' and find the users and use cases to use it. 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.

to post comments

Distributors ponder a systemd change

Posted Jun 16, 2016 16:18 UTC (Thu) by Wol (subscriber, #4433) [Link]

> 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