3 ms·
"but nowadays there are almost certainly better ways to solve this without letting these pre/post setup commands run as root." How? The only clean solution I
by hutzlibu 5y ago
"but nowadays there are almost certainly better ways to solve this without letting these pre/post setup commands run as root."
How?
The only clean solution I see (now or anytime in the past), would be to rewrite that "Actual Business Stuff" using the whole.
But that is expensive, maybe very expensive (I think this was clients code and going around and telling them to change maybe complex code of theirs ... is not something you want or can afford to do) So they just patched the hole up as much as they could do.
So I do consider it a patch(especially if the hardcoded commands as strings are verified commands and do not change or induce something else). Just maybe none that provides full security. But when you look at the state of things in IT in general ... I would say, there is indeed improvement, if at least gaping holes like this one gets fixed.
- Johnny555 5y agoHow? No way to answer that without knowing why it needs root. especially if the hardcoded commands as strings are verified commands and do not change or induce something else But now that invoked program becomes another weak link that can be exploited. And you don't even know what those innvoked commands are so don't know if anything can be hardcoded other than the path to the executable. Yes, it's an improvement in security, but it's only one step that probably won't be revisited until, for example, someone finds out that there's an easily exploited buffer overflow in one of those invoked programs that run as root.