From: hemant <gethemant@...>
Date: 2010-04-30T19:28:42+09:00
Subject: Re: Use of STDOUT.flush after puts

Hi

On Fri, Apr 30, 2010 at 1:13 PM, Charles Oliver Nutter
<headius@headius.com> wrote:
>
> IO.popen doesn't require IO#reopen to be available to users, so I'm
> not sure what you mean by that. It may do something similar to reopen
> under the covers, but that's an implementation detail.
>
> My primary gripe is the changing class; at worst, IO#reopen should
> only change the class to some common superclass, so that reopening a
> File stream with a Socket would turn it into an IO. But at best, the
> class shouldn't change at all; no other behavior in all of Ruby can
> cause an object to change its effective type out from under you.
> Consider this goofy sort of exploit:
>
> class MeanIO < IO
>  def initialize(io)
>    super(io.fileno)
>    @io = io
>  end
>
>  def write(data)
>    $stderr.puts "sending your data to hacker!"
>    $remote_hacker.receive(data)
>    super(data)
>  end
> end
>
> $stdout.reopen(MeanIO.new($stdout))
>
> puts 'password:aSdFgH'
>
> Now of course you could do similar sorts of things by simply class <<
> $stdout, but the problem with reopen is that I can't even freeze a
> class somewhere to prevent this from happening. $SAFE can prevent you
> from reopening on an "untainted IO", but you have to go up to level 4
> before that happens...plus I believe only MRI supports SAFE fully
> (JRuby has some minimal support for tainting, but does not implement
> SAFE levels).
>
> So yeah, I appreciate that "reopen" is the typical way people redirect
> IO, but in this case it breaks Ruby's class/object model in a really
> nasty way. Perhaps $stderr and friends should not be some sort of
> DelegateIO that has a reopen, but which doesn't change its class. Or
> perhaps not changing the class and letting the user fail if they try
> to call unsupported methods is best. At any rate, for a strongly-typed
> language like Ruby, objects *should not* change their class under any
> circumstances.
>

And was this discussed on ruby-core, it seems same behaviour can be
achieved without changing the class (or if required changing to some
superclass)?



-- 
Let them talk of their oriental summer climes of everlasting
conservatories; give me the privilege of making my own summer with my
own coals.

http://gnufied.org