This only affected users who went out of their way to disable this security feature. Presumably Google QA had this enabled on all their machines.
sudo rm -Rf /var
SIP is intended to protect against malicious software and against users accidentally hosing their system; there are legitimate reasons for disabling it. This was not anyone's fault but Google's.
It’s not just a QA issue - it’s a design flaw.
rm /varI mean, he can't be all that murdery, right?
We're talking about nuking a filesystem, not glitching out randomnly. That it hasn't nuked the filesystem before is not extenuating circumstances. It doesn't speak to character either.
People here sometimes.
But I am rather pissed at Apple because SIP is a global switch and with it enabled, there are several significant, legitimate things you cannot do with your own computer. SIP should work like sudo, not like a meta version of root. If it did so, nobody would have been affected by this week's Google nonsense.
For those wondering about such a use case: the only way to get eGPU's working on <=2015 MBPs is to disable SIP (and use purge-wrangler). It's not officially supported because 2015s don't have TB3
Doing something stupid and relying on the safety equipment to save you is a stunt. Doing it with someone else's stuff is being an asshole. This is not the behavior of sober grown-ups.
That doesn't protect you fully. You still have to check that $myfile is not undefined or "", but it helps with related problems and it tends to arrange the code in such a way that the lack of further sanity checks sticks out a bit more.
1) included code that performed dangerous system-level operations, despite the fact that
2) the included code was guaranteed to fail under the expected / default OS configuration?
The only logic I could see for such a state would be "let's teach them a lesson" for those users who chose to operate in the "dangerous" configuration. It doesn't make sense why they'd even attempt the symlink removal.
Which is the cause of like 90% of accidental "rm -rf /"s in history.
If this were an individual working alone (or even a small company), I'd have some sympathy. But Google has enough to pay QA engineers and build a sufficiently sophisticated test lab. They should get no pass for this.
I'm always finding people doing string arithmetic instead of using the APIs. Sometimes I catch myself doing it.
Rails got close to a solution by half-assedly tracking the provenance of all strings passed into certain functions. We could probably use a bit more of that.
All it would have taken is testing the installer on a non-SIP Mac.
But even when I have a QA team, which is less and less often, I like the devs to be involved in setting up stuff like this. QA is often not so good at engineering robust tests. But if they could write better code than we can they’d make more money as devs. So I’m still not letting the devs off the hook.
This class of error comes down to our chronic insistence on using stringly typed APIs for path/URI manipulation. It’s tantamount to a SQL injection attack, but with less data in the “query” instead of more. You should not be assembling file paths for destructive writes or deletes by string concatenation. But this is on almost nobody’s radar.
Is anyone else in this thread advocating for a change in software design? Mostly we are all blaming Google for fucking up. This is the headspace everyone but PHP was in for SQL fifteen years ago.
Like most failures, the analysis needs to identify a chain of events involving various failures; perhaps it would go something like this:
1. Industry and libraries commonly use strings for path/URI manipulation.
2. A software engineer did so in the installer and made a typo.
3. Code review did not identify the problem.
4. QA (and the CI process) didn't test on a Mac that was either old enough not to have SIP or had SIP disabled.
5. Many Mac users, especially in specialized environments running custom or specialized kernel extensions and drivers, use macOS with SIP disabled.
6. Chrome is widespread enough that some users in (5) downloaded the update. That subset had their Mac systems hosed.
I would identify (2), (3), and (4) as problems in the chain where Google carries blame.