configparser v/s file variables

[Steven D'Aprano]

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