durusmail: quixote-users: What's needed to get filesystem-mapping module into Quixote 0.6?
What's needed to get filesystem-mapping module into Quixote 0.6?
2003-01-28
REST and Quixote and FSM
2003-01-29
What's needed to get filesystem-mapping module into Quixote 0.6?
2003-03-05
2003-03-06
2003-03-06
2003-03-06
2003-03-06
What's needed to get filesystem-mapping module into Quixote 0.6?
Jonathan Corbet
2003-03-06
> I must confess I find the CGIScript class kind of unsettling.  The
> class uses the 2.2 'email' package, it changes sys.std{in,out} and
> then puts them back, and it modifies os.environ; all of this is kind
> of worrying.

It also, as far as I can tell, gives external scripts full access to
anything they can import within the Quixote server process.  As long as you
trust your scripts, you should be OK, I guess.

Also, I see things like:

+        original_sys_path = sys.path
+        sys.path.insert(0, self.folder)

...but that changes original_sys_path too, since it's the same list, not a
copy.  It needs to be something like:

        sys.path = [self.folder] + sys.path

so that a new list gets made.

I guess the real question I would ask is "why?"  Web servers can run CGI
scripts, and they have all the infrastructure needed to do it (relatively)
securely.  Given that this patch only runs *Python* CGI scripts, I would
suggest that most people could (1) just run them from the web server
directly, or (2) hook them properly into the Quixote application.  I would
vote against the CGIScript capability.

Just looking at the patch, I see that the StaticFilesFolder class puts in
an entry for "..", but I don't see how you could follow it without getting
a TraversalError.  I also question the wisdom of caching file contents; the
operating system already does that, and you'll just be taking up memory to
duplicate that cache.  That can be turned off, at least.

jon

reply