Forum: Ruby Redef undef'ed methods?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Robert F. (Guest)
on 2006-03-31 11:59
(Received via mailing list)
How "final" is a call to undef_method? Is there any way to get the
method back, ie. hook it up to the class again?

From my understanding of the C code it seems impossible since the
function/method pointer is set to 0 and there is no way from Ruby to
access the original value for that pointer again (unless you have
extracted "it" earlier with one of the "*method" methods). Is this
analysis correct?

If so code like

module Kernel
  [:eval, :system, :exec, :callcc, :`,               # `
   :set_trace_func, :sleep, :syscall].each do |m|
    undef_method m
  end
end

class Module
  [:module_eval, :class_eval,
   :define_method, :method, :instance_method,
   :private_class_method].each do |m|
    undef_method m
  end
end

class Object
  [:instance_eval].each {|m| undef_method m}
end

etc would give a possibility for a kind of simple, fine-grained
"sandboxing"? (I'm not implying you should do this instead of
tainting/SAFE-levels etc, just exploring possibilities)

Thanks,

Robert F.
Florian GroÃ? (Guest)
on 2006-03-31 18:01
(Received via mailing list)
Robert F. wrote:

> How "final" is a call to undef_method? Is there any way to get the
> method back, ie. hook it up to the class again?
>
> [...]
> etc would give a possibility for a kind of simple, fine-grained
> "sandboxing"? (I'm not implying you should do this instead of
> tainting/SAFE-levels etc, just exploring possibilities)

_why is using this already with great success for his TryRuby sandbox.
I'm not sure if there is ways around it, but it seems quite unlikely.

But you will definitely have to make sure that there is no way of
loading C extensions. It would be possible to get back the original
functions that way and do even worse.
Robert D. (Guest)
on 2006-03-31 18:35
(Received via mailing list)
On 3/31/06, Florian GroÃ? <removed_email_address@domain.invalid> wrote:
>
>
>
>
> class A
   alias_method :b, :a
    undef_method :a
end

...

class A
    alias_method :a, :b
end

Obviously I missed something ;)!

Cheers
Robert

--
Deux choses sont infinies : l'univers et la bêtise humaine ; en ce qui
concerne l'univers, je n'en ai pas acquis la certitude absolue.

- Albert Einstein
Robert F. (Guest)
on 2006-03-31 18:44
(Received via mailing list)
On 3/31/06, Robert D. <removed_email_address@domain.invalid> wrote:
> ...
>
> class A
>     alias_method :a, :b
> end
>
> Obviously I missed something ;)!
>
Yes, that will work around. Also you can do it with define_method if
you have a handle to the undef'ed method. However, these "holes" can
be covered by undef'ing more methods (ie alias_method etc) so it might
still be a useful technique for some situations.

Thanks,

Robert F.
Florian GroÃ? (Guest)
on 2006-03-31 21:14
(Received via mailing list)
Robert F. wrote:

> Yes, that will work around. Also you can do it with define_method if
> you have a handle to the undef'ed method. However, these "holes" can
> be covered by undef'ing more methods (ie alias_method etc) so it might
> still be a useful technique for some situations.

Or by undefing the methods before anyone has a chance of creating
aliases or using .instance_method()? :)
This topic is locked and can not be replied to.