ruby1.9, rails & $SAFE=1
Trying to use $SAFE=1 (just wanted to put some processing in a drb server) make rails unusable: it can't load some paths, data recovered from the DB are tainted, etc. For instance:
rails console
Loading development environment (Rails 3.0.0)
ruby-1.9.2-p0 > $SAFE=1; User.first
SecurityError: Insecure operation - file?
from .rvm/gems/ruby-1.9.2-p0/gems/activesupport-3.0.0/lib/active_support/dependencies.rb:408:in `file?'
it just fails to load user.rb file
if I try to do User.first before setting path (so files were already loaded) it works but it will fail letter getting other data since some data from activerecord seems to be tainted. Errors like this:
trace: .rvm/rubies/ruby-1.9.2-p0/lib/ruby/1.9.1/bigdecimal/util.rb:26:in `BigDecimal'
.rvm/rubies/ruby-1.9.2-p0/lib/ruby/1.9.1/bigdecimal/util.rb:26:in `to_d'
.rvm/gems/ruby-1.9.2-p0/gems/activerecord-3.0.0/lib/active_record/connection_adapters/abstract/schema_definitions.rb:166:in `value_to_decimal'
.rvm/gems/ruby-1.9.2-p0/gems/activerecord-3.0.0/lib/active_record/connection_adapters/abstract/schema_definitions.rb:77:in `type_cast'
.rvm/gems/ruby-1.9.2-p0/gems/activerecord-3.0.0/lib/active_record/connection_adapters/abstract/schema_definitions.rb:114:in `extract_default'
.rvm/gems/ruby-1.9.2-p0/gems/activerecord-3.0.0/lib/active_record/connection_adapters/mysql_adapter.rb:52:in `extract_default'
.rvm/gems/ruby-1.9.2-p0/gems/activerecord-3.0.0/lib/active_record/connection_adapters/abstract/schema_definitions.rb:34:in `initialize'
.rvm/gems/ruby-1.9.2-p0/gems/activerecord-3.0.0/lib/active_record/connection_adapters/mysql_adapter.rb:439:in `new'
.rvm/gems/ruby-1.9.2-p0/gems/activerecord-3.0.0/lib/active_record/connection_adapters/mysql_adapter.rb:439:in `block in columns'
.rvm/gems/ruby-1.9.2-p0/gems/activerecord-3.0.0/lib/active_record/connection_adapters/mysql_adapter.rb:439:in `each'
.rvm/gems/ruby-1.9.2-p0/gems/activerecord-3.0.0/lib/active_record/connection_adapters/mysql_adapter.rb:439:in `columns'
.rvm/gems/开发者_运维百科ruby-1.9.2-p0/gems/arel-1.0.1/lib/arel/engines/sql/relations/table.rb:78:in `columns'
.rvm/gems/ruby-1.9.2-p0/gems/arel-1.0.1/lib/arel/engines/sql/relations/table.rb:64:in `attributes'
.rvm/gems/ruby-1.9.2-p0/gems/arel-1.0.1/lib/arel/algebra/relations/relation.rb:177:in `[]'
.rvm/gems/ruby-1.9.2-p0/gems/activerecord-3.0.0/lib/active_record/relation.rb:312:in `primary_key'
.rvm/gems/ruby-1.9.2-p0/gems/activerecord-3.0.0/lib/active_record/relation/finder_methods.rb:291:in `find_one'
.rvm/gems/ruby-1.9.2-p0/gems/activerecord-3.0.0/lib/active_record/relation/finder_methods.rb:281:in `find_with_ids'
.rvm/gems/ruby-1.9.2-p0/gems/activerecord-3.0.0/lib/active_record/relation/finder_methods.rb:107:in `find'
.rvm/gems/ruby-1.9.2-p0/gems/activerecord-3.0.0/lib/active_record/base.rb:439:in `find'
This error can be caused manually doing:
rails console
Loading development environment (Rails 3.0.0)
ruby-1.9.2-p0 > $SAFE=1
=> 1
ruby-1.9.2-p0 > a = "1"
=> "1"
ruby-1.9.2-p0 > a.to_d
=> #<BigDecimal:3adca98,'0.1E1',9(18)>
ruby-1.9.2-p0 > a.taint
=> "1"
ruby-1.9.2-p0 > a.to_d
SecurityError: Insecure operation - BigDecimal
from .rvm/rubies/ruby-1.9.2-p0/lib/ruby/1.9.1/bigdecimal/util.rb:26:in `BigDecimal'
from .rvm/rubies/ruby-1.9.2-p0/lib/ruby/1.9.1/bigdecimal/util.rb:26:in `to_d'
from (irb):6
from .rvm/gems/ruby-1.9.2-p0/gems/railties-3.0.0/lib/rails/commands/console.rb:44:in `start'
from .rvm/gems/ruby-1.9.2-p0/gems/railties-3.0.0/lib/rails/commands/console.rb:8:in `start'
from .rvm/gems/ruby-1.9.2-p0/gems/railties-3.0.0/lib/rails/commands.rb:23:in `<top (required)>'
from <internal:lib/rubygems/custom_require>:33:in `require'
from <internal:lib/rubygems/custom_require>:33:in `rescue in require'
from <internal:lib/rubygems/custom_require>:29:in `require'
from script/rails:6:in `<main>'
ruby-1.9.2-p0 >
Any idea how to use rails and $SAFE=1 together?
As far as I know, there was no real efforts in trying to make Rails run in $SAFE
mode of Ruby. There would be whole lot of problems doing so - you'll have to deal with dynamic loading (and re-loading) of model & controller files, routing (manually untainting data that comes from the outside world), etc, etc.
Rails core team expressed their view several times on supporting $SAFE
variable in Rails: basically, it boils down to:
$SAFE
is not an absolute protection - it might save from SQL injections and similar attacks, but it won't really help against XSS attacks, cookie stealing/sniffing, generally unsecure design, etc, etc.$SAFE
support is fairly clumsy to implement and would slow down the whole thing considerably. Even if it would be off by default, doing extra.untaint
calls everywhere would yield some speed penalties.
People occasionally report some success in running various parts of Rails in $SAFE
environment in mailing lists, but it's usually limited to stuff like ERB/ERuby or other templating engine.
精彩评论