From: daz <dooby@...10.karoo.co.uk>
Date: 2004-03-08T00:59:41+09:00
Subject: Re: freeze, frozen? in extensions


ts wrote:
> >>>>> "d" == daz  <dooby@d10.karoo.co.uk> writes:
>
> d> As a Ruby String points to a C string, it would easily be possible for
> d> an ext just to overwrite part of the C string even if it had been frozen
> d> but (you made me think) Ruby objects *always* are/should be modified via
> d> the API rather than directly which allows Ruby to check things such as
> d> /frozen/ status.
>
>  well, I can give you an exception. In plruby you have
>
>         vid = INT2NUM(typoid);
>         klass = rb_hash_aref(plruby_classes, vid);
>         if (NIL_P(klass)) {
>             klass = rb_hash_aref(plruby_conversions, vid);
>             if (NIL_P(klass)) {
>                 st_insert(RHASH(plruby_classes)->tbl, vid, Qfalse);
>             }
>             else {
>                 klass = rb_const_get(rb_cObject, NUM2INT(klass));
>                 st_insert(RHASH(plruby_classes)->tbl, vid, klass);
>             }
>         }
>
>  It's trying to search if it exist a class associated with a postgres type,
>  to call a conversion method.
>
>  Now there is rb_hash_aref() but it use st_insert() rather than
>  rb_hash_aset(). The reason is simple, plruby can run with $SAFE >= 4 and
>  in this case ruby will give an error
>
> svg% ruby -e 'a = {}; $SAFE = 4; a[12] = 24'
> -e:1:in `[]=': Insecure: can't modify hash (SecurityError)
>         from -e:1
> svg%
>
>  because I'm *sure* that it don't exist a security problem in this case it
>  use st_insert() rather than the standard API function to bypass the
>  security mechanism
>
>
> Guy Decoux
>


I'm checking for holes in my life-boat.

3-)


daz