I’m currently trying to get jruby-sandbox working in an applet for the
sake of a project I’m doing. From what I’ve seen, jruby-sandbox is the
best implementation of a sandbox in any ruby version out there. It
seemed like a logical choice for a project where I would run ruby code
in a browser that was submitted by users. But, no matter what I attempt,
I just can’t seem to get it to work. Here is what I’ve done so far:
- Switched to jruby 1.6.8 because 1.7.x support for applets seems to be
broken?
- Figured out rubygems won’t work in an applet for whatever reason.
This forced me to install my gems into the main library folder of my
jruby jar.
- Wasted time trying to figure out how to load a nested jar file in
jruby. (As it turns out, it only works if your jars are unsigned. It’d
be nice to know how to get around that, because I would like to sign my
jar.)
- Finally gotten the sandbox to load from an unsigned jar locally,
but…
- Wasted much more time trying to figure out why the sandbox fails to
load in an applet with the following error:
LoadError: Exception loading extension ‘sandbox.SandboxService’:
java.lang.NullPointerException
from org/jruby/RubyKernel.java:1062:in ‘require’
from classpath:/META-INF/Jruby.home/lib/ruby/1.8/sandbox.rb:1:in
‘(root)’
from org/jruby/RubyKernel.java:1062:in ‘require’
from classpath:/META-INF/Jruby.home/lib/ruby/1.8/sandbox.rb:1:in
‘evaluate’
from org/jruby/RubyKernel.java:1112:in ‘eval’
from classpath:/META-INF/Jruby.home/lib/ruby/1.8/irb.rb:158:in
‘eval_input’
from classpath:/META-INF/Jruby.home/lib/ruby/1.8/irb-rb:271:in
‘signal_status’
from classpath:/META-INF/Jruby.home/lib/ruby/1.8/irb.rb:155:in
‘eval_input’
from org/jruby/RubyKernel.java:1439:in ‘loop’
from org/jruby/RubyKernel.java:l2l2:in ‘catch’
from classpath:/META-INF/Jruby.home/lib/ruby/1.8/irb.rb:154:in
‘eval_input’
from classpath:/META-INF/Jruby.home/lib/ruby/1.8/irb.rb:71:in ‘start’
from org/jruby/RubyKernel.java:1212:in ‘catch’
from classpath:/META-INF/Jruby.home/lib/ruby/1.8/irb.rb:70:in ‘start’
from :1:in ‘(root)’
from org/Jruby/RubyProc.java:270:in ‘call’
from org/Jruby/RubyProc.java:224:in ‘call’
Since this problem only occurs when loading the sandbox from an applet,
I looked at the source of the SandboxService class to see if it was
doing anything an applet wouldn’t allow. But, with my admittedly limited
knowledge of Java, I was unable to find anything. My options at this
point are, to get ruby-sandbox working… somehow, to write my own
sandbox (which if I could mange to do in pure Ruby would certainly be a
worthwhile endeavor), or to give up entirely. I don’t like that last
one, but I have no idea how to accomplish the first, and the second one
would add a very large amount of work to what would already be a large
project. Taking that in to consideration, does anyone have any ideas how
I can make jruby-sandbox work?
Keith B. wrote in post #1096067:
Unfortunately I have no idea about this, but I did notice that the
filespecs say 1.8, and was wondering if you’re using JRuby in 1.8 mode,
and if that was intentional.
Yes, and the reason is, the applet class is just plain broken in 1.9.
Apparently it isn’t being maintained, which is a shame, as I think it
has potential.
A while back, I think it was at 1.7.0, 1.9 mode became the default.
Before then the default mode was 1.8 and it was necessary to specify
–1.9 to enable 1.9 mode. If you haven’t already, you might want to try
1.9 mode to see if that helps.
Nope. Actually I’d like to know how to force 1.8 as opposed to 1.9,
since I have to use 1.8, and not being able to force it leaves me stuck
with the obsolete jruby 1.6.8 as my base. I just don’t know how to do
that in the context of an applet.
Unfortunately I have no idea about this, but I did notice that the
filespecs say 1.8, and was wondering if you’re using JRuby in 1.8 mode,
and if that was intentional.
A while back, I think it was at 1.7.0, 1.9 mode became the default.
Before then the default mode was 1.8 and it was necessary to specify
–1.9 to enable 1.9 mode. If you haven’t already, you might want to try
1.9 mode to see if that helps.
Keith R. Bennett
Ano -
On Feb 9, 2013, at 7:36 AM, Ano H. [email protected] wrote:
Keith B. wrote in post #1096067:
Unfortunately I have no idea about this, but I did notice that the
filespecs say 1.8, and was wondering if you’re using JRuby in 1.8 mode,
and if that was intentional.
Yes, and the reason is, the applet class is just plain broken in 1.9.
Apparently it isn’t being maintained, which is a shame, as I think it
has potential.
My understanding based on what I’ve read in recent weeks in the tech
news, is that Java applets are extremely vulnerable, and can offer
control of a system to hackers, and that this will not be fixed for a
pretty long time (half year at least, I believe). Given that, I
wouldn’t want to use them unless it was on a local network that was
tightly controlled. Is this not an issue for you?
A while back, I think it was at 1.7.0, 1.9 mode became the default.
Before then the default mode was 1.8 and it was necessary to specify
–1.9 to enable 1.9 mode. If you haven’t already, you might want to try
1.9 mode to see if that helps.
Nope. Actually I’d like to know how to force 1.8 as opposed to 1.9,
since I have to use 1.8, and not being able to force it leaves me stuck
with the obsolete jruby 1.6.8 as my base. I just don’t know how to do
that in the context of an applet.
I believe the option is --1.8. One way to set it is as an environment
variable “JRUBY_OPTS”. Here’s a StackOverflow page that shows a way to
set one for an applet:
During the initialization phase, the 1.9 mode requires access to the
absolute paths, which is not allowed in the applet environment.
There should be a JIRA ticket about this.
Keith B. wrote in post #1096070:
My understanding based on what I’ve read in recent weeks in the tech
news, is that Java applets are extremely vulnerable, and can offer
control of a system to hackers, and that this will not be fixed for a
pretty long time (half year at least, I believe). Given that, I
wouldn’t want to use them unless it was on a local network that was
tightly controlled. Is this not an issue for you?
Yea, I know, what lousy timing. My project revolves around the idea or
allowing people to write ruby code that gets executed in jruby applets
running in other people’s browsers. So security could be considered a
somewhat important consideration. Hence, the need for a sandbox. As long
as I’m not giving anyone power to run Java code directly, or call
exploitable Java methods, it should keep the risk of someone exploiting
my applet to a minimum. At least in theory.
Frankly, something like emscripted-ruby
(GitHub - replit-archive/emscripted-ruby: Ruby 1.8.7 compiled to JavaScript) could be considered a better
solution, but it has a memory leak issue which may become a real problem
when people who use my site start getting out of memory errors. Plus I’d
still need to write a sandbox implementation for it.
I believe the option is --1.8. One way to set it is as an environment
variable “JRUBY_OPTS”. Here’s a StackOverflow page that shows a way to
set one for an applet:
Are params passed to the applet actually equivalent to environmental
variables? I’ll try messing around with it later and see I can use them
to get a jruby 1.7.1 applet to load.