configparser v/s file variables
Steven D'Aprano
steve+comp.lang.python at pearwood.info
Thu Jun 28 19:44:00 EDT 2018
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
More information about the Python-list
mailing list