On Wednesday 05 August 2015 05:59, Ben Finney wrote: > marco.naw...@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 -- https://mail.python.org/mailman/listinfo/python-list
