On Wed, Feb 19, 2003 at 03:37:13PM -0500, Guido van Rossum wrote: > I can interpret world-readable in two ways. On Unix, it traditionally > means that anybody with a login name can read it. Since Apache > typically runs as user nobody, CGI scripts have to be world-readable > as well. I started writing three separate emails to play devil's advocate here and "prove guido wrong", but half way through each email I realized that there really isn't much of a vulnerability here. I originally considered the premise that CGI's must be world readable (perhaps o+x would suffice) - it did not. What about if MyCGI.py imports MySecretPasswords and MySecretPasswords is in .pyc format - nope, that needs to be o+r also. What about if MyCGI.py reads a file MySecretPasswords.txt or evals the statements contained within? Nope, MySecretPasswords.txt must be o+r. Bottom line: if the webserver is going to access it, or hand it to python to access, it's got to be o+r. And under those circumstances, Guido's right on in his statement of "if they are putting passwords in o+r modules, anyone with an account will be able to view them." The *only* possibility I could come up with was attaching to a remote interpretter an asking it to execute modules you feed it (you specify the path to the module). Under that scenario one could run the interpretter as a legitimate user and access files the webserver could not access. That seems like a really big stretch and if you did go that route you'd probably build in functionality to handle remote exceptions so that code with passwords was not exposed to the remote client. Respectfully, -c -- 4:00pm up 121 days, 7:35, 1 user, load average: 0.08, 0.26, 0.40
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4