How is "don't give a config file an arbitrary writable open() call" security by obscurity? What is being hidden? That's not really how that term works. I also d

How is "don't give a config file an arbitrary writable open() call" security by obscurity? What is being hidden? That's not really how that term works. I also don't understand your invocation of defense in depth or the (wrong) comparison you are trying to make. Can you reframe your rebuttal without loaded security terms that don't fit what you're saying? The point GP is making, and with which I agree, is that executable configurations can be dangerous if not sandboxed and even then still carry an elevated risk versus a parser. We are speaking relatively; it is absolutely still a risk to parse user input as a config, but less so than a full programming environment being immediately available to a malicious config writer. Stepping back and identifying the malicious vector is worth it here, though, as there's a case to be made that configurations are the domain of administrators and should be secured accordingly via external means. Then the problem is recentered.