list at joreybump.com
Mon Mar 14 21:16:21 EST 2005
Graham Dumpleton wrote: > The only workaround you would have in the short term is not to use > an "index.py" file and always name it something different. Always good advice. The only time I would even consider using a module named index.py would be as in Jan's example, where one might want to run an entire site with mod_python transparently. > This is actually a security hole because any __auth__ stuff would > be visible and thus people could work out login/passwd. This may > require another security fix release of mod_python. :-( No argument here, any information leak is a security hole and should be fixed. But, even with __auth__, there's no good reason to store login details in the module or anywhere within the DocumentRoot, for that matter. > Jan Huelsbergen wrote .. > >>The mod_python.publisher documentation states at >>http://modpython.org/live/current/doc-html/hand-pub-alg-trav.html that >>if >>"Any of the traversed object's names begin with an underscore ("_")." >>they are not accsessable through the web, yet, when I put a >>_foo = 'bar' >>in my index.py, http://my.site/_foo returns 'bar'. >> >>Am I missinterpreting the documentation? >>How to protect a variable from outside access? I've been creating all of my mod_python applications as packages that sit in a directory outside of the DocumentRoot. I use the PythonPath directive to append the directory to the module search path. Then I import enough of the package to bootstrap my published module, which might contain a single function that acts as a frontend to a dispatcher. It might sound like a lot of work, but with good planning it can set a solid foundation for future projects, thus saving a *lot* of time in the long run. By using this approach, along with dotted notation imports, explicit restriction of *from imported objects with __all__, and enclosing almost everything in functions, I haven't been affected by any of the recent security issues, including this one. You can even take this to an extreme and obfuscate your login details and imported names so that they would not be human readable or even grepped (haven't gone there, yet). Example: ~/python/ domain/ __init__.py database.py html.py foo/ __init__.py database.py form.py bar/ __init.py database.py util.py Then the published module might look like this: #foo.py import domain.foo def start(req): """ Public interface to application backend. """ return domain.foo.dispatch(req) Nothing's exposed, lots of reusable code, provides for separation between modules, and results in excellent caching of imported modules and database connections. The only downside is that it makes you more dependent on a test environment, because it is sometimes necessary to restart apache to force a reload of imported modules that have been updated.