Most Pythonic way to store (small) configuration

Steven D'Aprano steve+comp.lang.python at pearwood.info
Wed Aug 5 10:32:26 CEST 2015


On Wednesday 05 August 2015 05:59, Ben Finney wrote:

> marco.nawijn at colosso.nl writes:
> 
>> Why not use Python files itself as configuration files?
> 
> Because configuration data will be user-editable. (If it's not
> user-editable, that is itself a poor design choice.)
> 
> If you allow executable code to be user-edited, that opens your program
> to arbitrary injection of executable code. Your program becomes wide
> open for security exploits, whether through malicious or accidental
> bugs, and simple human error can lead to arbitrary-scope damage to the
> user's system.

Yeah... it's almost as if you allowed the user to edit the source code of 
your application, or even write their own code. And nobody would do that! 

*wink*

I'm not entirely disagreeing, just adding some nuance to the discussion.

My own personal feeling is that using code as config is a little 
disquieting. It's a bit of a code smell. Do you really need that much power 
just to allow people to set some configuration settings? Using a Turing 
Complete programming language just to set a bunch of name:value pairs seems 
to be gross overkill.

But on the other hand, config systems do tend to grow in power. People often 
want conditional and computed settings. Rather than invent your own (buggy) 
mini-language to allow conf like this:

if $PLATFORM = 'Windows' set location = 'C:\The Stuff';
if $PLATFORM = 'Linux' set location = $baselocation + '/thestuff';

using Python seems like a much better idea.

Code smell or not, I don't think that Python code as config is that much of 
a problem, for most applications. Yes, the user can insert arbitrary code 
into their config file, and have it run... but it's their user account 
running it, they presumably could just insert that code into a file and run 
it with python regardless. There's (usually) no security implications.

Although I can think of some exceptions. For example, the company I work for 
has a Linux desktop designed for untrusted, hostile users (prisoners in 
jail), and using .py files as config would *definitely* not be allowed for 
that. But I think that's an exceptional case.


> On another dimension, configuration files specifying the behaviour of
> the system are much more useful if their format is easily parsed and
> re-worked by tools the user chooses.
> 
> Your program should not be the only tool (and Python should not be the
> only language) that can read and/or write the configuration data with
> straightfoward data manipulation.

Python is an open standard that anyone can use, or write their own should 
they wish. If you don't like CPython, use Jython or PyPy or 
MyFirstPythonInterpreter to pass the config data. 

A better argument may be that *running arbitrary code* should not be 
required in order to parse a config file. I'm sympathetic to that argument 
too. But if that's your worry, and you absolutely must read a .py config 
file, you could write your own stripped down interpreter of a limited subset 
of the language, and use that. No, it won't be able to determine all the 
config settings from arbitrary .py files, but it may give you a practical 
solution which is good enough for what you need.


> So a complex full-blown programming language like Python is a poor
> choice for configuration data for that reason, too.
> 
> Much better to choose a tightly-defined, limited-scope configuration
> data format that you can be confident any user cannot employ to run
> arbitrary code.

Sure, if your config requirements are met by such a data format.


-- 
Steve



More information about the Python-list mailing list