Changes between Version 28 and Version 29 of SplitSettings

Timestamp:

Aug 14, 2012, 6:52:11 PM (12 years ago)

Author:

wiml

Comment:

My approach: exec and open()

SplitSettings

@@ -266 +266 @@
 # More development/maching specific settings
 }}}
+
+== Using exec to incorporate local settings ==
+
+I've been using code like this to incorporate local settings:
+
+`settings.py`
+{{{
+#!python
+# Non-machine-specific settings live directly in settings.py
+# Machine-specific settings live in another file, perhaps local_settings.conf
+
+exec open('local_settings.conf') in globals()
+}}}
+
+This allows the local settings to both read and modify the main settings' values (and it's simple).
+
+As an enhancement, a small amount of privilege separation can be had by making the `local_settings.conf` file unreadable by the uid that runs the web app, opening local_settings.conf in a setuid wrapper, passing its file descriptor to the Django process, and using {{{exec os.fdopen(..., 'r') in globals()}}}. This isn't perfect, since any secrets read from that file are still stored in the Django process, but it does make it harder for someone who has gained access to the user id running the Django app to discover your secrets. (Obviously all of the Python files used by the app must be owned by a user other than the one the app runs as, as well.)
 
 == Using a list of conf files (Transifex) ==