[#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

Re: sandbox timers & block scopes

From: why the lucky stiff <ruby-core@...>
Date: 2006-08-22 16:56:15 UTC
List: ruby-core #8683
On Tue, Aug 22, 2006 at 06:02:04PM +0900, Yukihiro Matsumoto wrote:
> In message "Re: sandbox timers & block scopes"
>     on Wed, 9 Aug 2006 03:09:32 +0900, why the lucky stiff <ruby-core@whytheluckystiff.net> writes:
> 
> |1. Ruby uses setitimer to switch threads.  I would like to use setitimer as well
> |to abort a sandbox which runs longer than its timeout.  Can anyone recommend a
> |signal which can be used for this?  Or could I get access to the thread
> |switching routine so I can check sandbox timeouts between threads?  Or, perhaps
> |there is another strategy.
> 
> I think you've solved this one.

Yes, I'll be fine.  I do have a small, related question about exception handling, matz.

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.

So, if the standard Ruby environment raises an exception, it cannot be caught by
the sandbox.  This is very nice if users want to create their own security
models.

  # setup security
  sand = Sandbox.new
  sand_k = sand.eval("Kernel")
  def sand_k.fork
    raise Exception, "User attempted to call fork!  Closing their sandbox!"
  end

  # execute user's string
  sand_k.eval(user_input)

The trouble is that, even though the user can't rescue the exception,
they can ensure.

  def endless
    begin
      fork
    ensure
      endless
    end
  end

I wondering if rb_ensure can only recover from exceptions raised which descend
from rb_cObject.  This is somewhat complicated since the sandbox will need to
use rb_ensure to catch the exception, to swap everything out and raise again.
Once rb_cObject is swapped back in, the exception could be caught.

> You have to replace ruby_dyna_vars for in-block local variables,
> ruby_frame and ruby_block for blocks.

Ah, oh, ruby_dyna_vars.  Thankyou, I will check this out!  To avoid exposing these, I 
will take a simpler approach for now and wrap every sandbox_eval call in a method.

_why

In This Thread