[#8484] strptime fails to properly parse certain inputs — <noreply@...>

Bugs item #5263, was opened at 2006-08-01 23:14

13 messages 2006/08/02
[#8485] Re: [ ruby-Bugs-5263 ] strptime fails to properly parse certain inputs — Yukihiro Matsumoto <matz@...> 2006/08/02

Hi,

[#8538] Re: [ ruby-Bugs-5263 ] strptime fails to properly parse certain inputs — nobu@... 2006/08/06

Hi,

[#8561] sandbox timers & block scopes — why the lucky stiff <ruby-core@...>

Two puzzles I am trying to solve:

28 messages 2006/08/08
[#8624] Re: sandbox timers & block scopes — why the lucky stiff <ruby-core@...> 2006/08/15

raise ThisDecayingInquisition, "anyone? anyone at all?"

[#8627] Re: sandbox timers & block scopes — MenTaLguY <mental@...> 2006/08/15

On Wed, 2006-08-16 at 00:35 +0900, why the lucky stiff wrote:

[#8628] Re: sandbox timers & block scopes — why the lucky stiff <ruby-core@...> 2006/08/15

On Wed, Aug 16, 2006 at 02:46:30AM +0900, MenTaLguY wrote:

[#8629] Re: sandbox timers & block scopes — "Charles O Nutter" <headius@...> 2006/08/15

On 8/15/06, why the lucky stiff <ruby-core@whytheluckystiff.net> wrote:

[#8690] a ruby-core primer — why the lucky stiff <ruby-core@...>

Hello, all. I've been working on the ruby-core page for the new Ruby site.

21 messages 2006/08/22

killing ensure (was Re: sandbox timers & block scopes)

From: why the lucky stiff <ruby-core@...>
Date: 2006-08-27 02:57:31 UTC
List: ruby-core #8726
On Wed, Aug 23, 2006 at 02:13:46PM +0900, Yukihiro Matsumoto wrote:
> Hi,
> 
> In message "Re: sandbox timers & block scopes"
>     on Wed, 23 Aug 2006 01:56:15 +0900, why the lucky stiff <ruby-core@whytheluckystiff.net> writes:
> 
> |From rb_rescue:
> |
> |  if (!rb_obj_is_kind_of(argv[0], rb_cModule)) {
> |      rb_raise(rb_eTypeError, "class or module required for rescue clause");
> |  }
> |
> |There is a very nice side effect of this code.  rb_eException is derived from
> |rb_cModule.  And sandkit->rb_eException is derived from sandkit->rb_cModule.
> 
> ? It is assuming that argv[0] to be an instance of subclass of Module,
> this means Foo in
> 
>   begin
>     ...
>   rescue Foo
>     ...
>   end
> 
> to be a module or a class, not that Exception to be a subclass of
> Module, but Exception to be an instance of a Class, which is true even
> within the sandboxes I guess.  Am I missing something?

I will try to approach this differently.  Is there a way to circumvent ensure?
In other words: can you kill this thread?

  th =
  Thread.start do
    def endless
      begin
        loop {}
      ensure
        endless
      end
    end

    endless
  end

I cannot.

  th.kill  # hangs
  th.raise Interrupt while th.active?  # eternal ping-pong

Now, let us see what Exceptions are in the sandbox and out of the sandbox.

  >> require 'sandbox'
  => true
  >> s = Sandbox.new
  => #<Sandbox:0x82da390>
  >> s.eval("Exception")
  => Exception
  >> Exception.is_a? Object
  => true
  >> s.eval("Exception").is_a? Object
  => false
  >> s.eval("Exception").is_a? s.eval("Object")
  => true

You see?  Normal rb_eException < rb_cObject.  But, kit->eException <
kit->cObject.

So, knowing all of that, it is insecure for `rescue` in the sandbox to catch a
normal rb_eException.  Ruby does, too.  Ruby won't allow it.  I also feel it is
insecure for `ensure` in the sandbox to intercept _some_ exceptions.  But
`ensure` even catches TAG_FATAL.  It is good at it's job!

_why

In This Thread

Prev Next