Most Pythonic way to store (small) configuration
Steven D'Aprano
steve+comp.lang.python at pearwood.info
Wed Aug 5 04:32:26 EDT 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