What I saw in these cases, the result was a few levels removed from the root cause and they'd add the same workaround to like 5 different places (and miss one or two) instead of tracking it back to the origin where the fix was that simple.
Usually something more subtle like adding an early return somewhere before the offending line, or inheriting from that class and blanking that method, or something along those lines.
I'm not GP, but in research very diverse teams are not uncommon. I'm on a team now in which I'm the embedded software engineer / Android SME and my coworker is the 4G LTE/5G NR SME.
I ask him 4G LTE/5G NR questions all the time. I don't know ahead of time if he'll know the answer, but (1) it'd be a solid bet that he does and (2) it's his responsibility to know it given his role.
What I mean is that for “honest” software, built-in to the OS or otherwise, the programmer finds a situation where they take some user-supplied input and concatenate that into a path, and call something like OS.read(). If they want to prevent the user from causing havoc, they now find themselves dealing with path validation in their software instead of calling OS.safeOpen(), which would be a reduced subset of allowed chars?
How is it permission denied if the app is running as admin? The OS "handled" it by giving admin app admin access. Sure, it was tricked by the user input, but that's what the fixes are for?
reply