configparser v/s file variables
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.
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson