On Thu, 28 Jun 2018 10:58:36 -0700, Jim Lee wrote: > On 06/28/18 07:30, Grant Edwards wrote: >> I still maintain it's a bad idea to run arbitrary code found in >> user-edited config files. >> >> There may be cases where somebody has figured out how to muck with a >> config file that's shared among multiple users, or has tricked somebody >> into including something from an untrusted source in an include file. >> >> Or there could be users who don't know what they're doing and >> unwittingly type something harmful into a config file: >> >> bad_command = os.system("rm -rf ~/*") >> >> Yes, I know, users would never be that dumb... >> > I agree with you that it's a bad idea.
Aside from the little fact that you described concerns about using Python code for settings as "silly". > I was pointing out that I look > at it from an input validation viewpoint rather than a security > viewpoint - that's all. You have made it abundantly clear that you aren't thinking about security. > Absolute security isn't a solvable problem. It isn't even a technical > problem. But that's a discussion for another time... Nobody is talking about "absolute security". We're talking about *one* aspect of security: given the need to collect user-supplied settings, is it acceptable to get the settings from executable Python code? Data validation is a red herring: it is no more or less necessary to validate user settings regardless of their source. Whether they come from reading an INI file or from importing a Python file, you still need to check that they have valid values. -- Steven D'Aprano "Ever since I learned about confirmation bias, I've been seeing it everywhere." -- Jon Ronson -- https://mail.python.org/mailman/listinfo/python-list