Robert Dober wrote:
> On 10/31/06, ara.t.howard / noaa.gov <ara.t.howard / noaa.gov> wrote:
>    <Ara's version of code snipped>
>>      harp:~ > ruby a.rb
>>      LOL: superclass method `lol' disabled
>
>
> It does the same as OP's code, I really feel this is strange.
> Rune, on philiosophical grounds, I prefer the second behavior the  
> super
> method being available again, can you elaborate on why you prefer the
> first?

I don't necessarily prefer the first, I prefer them to behave the  
same way.
Actually having the super method available makes more sense.

The reason I stumbled upon this is because I'm writing about  
sandboxing and
would like to explain how you can supply "safe" versions of classes  
in the
sandbox by "disabling" unsafe methods (of course it doesn't help if  
you can
simply redefine the method yourself, but it's a first step). When  
playing
around with undef_method and remove_method I found that remove_method  
only
removes method defined in the class it self (and not derived  
methods), while
undef_method prevents objects of the class from responding to the  
method (as
is explained in `ri Module.undef_method`). And then I found this  
inconsistency
in behavior.

While we're on it: any good suggestions for how to supply "safe"  
versions of
classes to the sandbox? Something like how Python's Bastion module is/ 
was
supposed to work (it's now deprecated, together with the RExec  
module). I
guess the best would be to call remove_method on the unsafe methods  
in the
classes they are defined, and hope that an attacker don't redefine  
the method
himself (which is hard to prevent).

-- 
Vennlig Hilsen / Regards
Rune Hammersland