Re:size_t-to-int vulnerability in Linux’s filesystem layer
by bigiain on Tuesday July 20, 2021 @08:23PM
(#27900878)
If the consequences of one server wedging itself is a "massive outage" and "unhappy customers", then you probably don't really care about that outage or those customers. If you don't have enough redundancy and alerting and automated disaster recovery to keep your customer facing shit up when one server panics, you're just relying on luck to keep your customers happy.
Fire an alert, remove that server from the load balancer, and fix the problem without your customers even noticing.
Or make sure if you're running a hobby-project architected platform that your customer expectations and SLAs are clear up front, and let it go down until Monday morning when you'll get around to fixing it.
Re:size_t-to-int vulnerability in Linux’s filesystem layer
by michaelmrose on Tuesday July 20, 2021 @07:36PM
(#27900566)
Or just don't put stuff that crashes in pid1
Re:size_t-to-int vulnerability in Linux’s filesystem layer
by modshatereality on Tuesday July 20, 2021 @10:31PM
(#27901718)
seriously, if you're doing allocations in pid1 you fucked up.
Re:size_t-to-int vulnerability in Linux’s filesystem layer
by afc on Tuesday July 20, 2021 @08:52PM
(#27901054)
Yeah, great idea: rather than worry about how to deal with software bugs, just never have bugs...
Re:size_t-to-int vulnerability in Linux’s filesystem layer
by a1369209993 on Wednesday July 21, 2021 @01:36AM
(#27902688)
Exactly. This is why systemd is a terrible design. The fastest and most secure code, that never crashes and never needs patching, is code that doesn't exist.
Re:size_t-to-int vulnerability in Linux’s filesystem layer
by michaelmrose on Tuesday July 20, 2021 @09:07PM
(#27901147)
runit.c is 330 lines of code
Keeping it small and simple to minimize bugs is perfectly viable and reasonable.
It depends really what your server does, and what the consequences of it doing the wrong thing are.