On 1/6/07, Matteo C. [email protected] wrote:
question is old but my searches on the web weren’t succesful…
[Note: I have not studied mod_ruby internals. I’m building on the
statement that all scripts run in the same interpreter]
There are several things a script can do:
call your objects’ methods - enumerate all objects (via
ObjectSpace.each_object), methods (via Object#methods) and call
private methods via Object#send. The similar for variables and
constants. Call any code in the context of the object either via
adding new method or using instance_eval
modify your classes/objects - the classes are open, trace/debug
your code via set_trace_func and/or rdebug/breakpoint etc.
see your source code using __SCRIPT_LINES
the other script runs with the same privileges as your script, so
it sees the same files - configs, data, etc.
In summary, the script can do almost anything security-wise.
anyway… let’s suppose I’ve my brand new application with its database
class which opens a connection to the db with the correct user and
password, and a session class wich keeps track of user sessions, login,
etc. then I put my program on a web hosting service
how should I write my classes so that a malicious script running on the
same web hosting service can’t access my db or get an authenticated
session by poking with my classes?
This is usually solved by not using mod_ruby The other way running
your script using webrick/mongrel/mod_fcgi within its own interpreter
and in case of mongrel/webrick reverse proxying them with an optional
load balancer (apache/pond/lighttpd/ngix/…) That way, each script
has its own interpreter running under different user. (From the above
the optimal one seems to be a bunch of mongrels behind something -
apache/pond/… - see mongrel.rubyforge.org)
_why was working on a sandbox that would allow separating code within
one interpreter, but I don’t know how far has he got (see
Finally something can be done using $SAFE_MODE, although that’s not a
fix for all of the above problems.
Problem with the above solutions might be that the webhosting provider
has to install them (unless you have a dedicated host or a VPS).
Fortunatelly many hostings provide mongrel&co for their clients.