ts <decoux / moulon.inra.fr> wrote in
<200101100926.f0A9QFR13027 / orsay1.moulon.inra.fr>: 

>
> Perhaps there are very good reasons to run it with $SAFE >= 3
>
> sand.rb contains your class
>
>pigeon% cat b.rb
>#!/usr/bin/ruby
>require 'sand'
>s = Sandbox.new
>s.execute("$stdout.reopen('b.rb', 'w'); $stdout.puts 'written'")
>pigeon% 
>
>pigeon% b.rb
>pigeon% 
>
>pigeon% cat b.rb
>written
>pigeon% 
>

As expected, there still seem to be (quite a lot) *securityholes* around!
I will go with level 3 for the moment! As I already mentioned before, the
reason for wanting 2 was the eval-statement. Matz, why is eval forbidden
in level 3? If I understood the security mechanism correctly, the
eval-"code" is executed on the same level as the eval-call itself? 

Another problem I encountered in the Sandbox is: 

class Context
  alias old_print print
  def print (*args)
    old_print("Cont'sPrint ->" + args.join)
  end

  def context
    return binding
  end
end

context = Context.new
eval(
"print ('hello')
class A
  def initialize
     ObjectSpace.define_finalizer(self, proc{|id|
       print \"\nfinal #{id}\"})
  end
end
a = A.new", context.context)

results in:
Cont'sPrint -> hello
final 84171884

Note: that the printing in the finalizer does not make use of Cont:print!
So it looks as if the the finalizing process is not executed in the same
context as the rest of this eval-code! Is this a Bug?
Clemens