Why is this allowed / possible?
class MyUltraSecretKeystore
private
def key
return "nobody-should-read-this-ever"
end
end
ks = MyUltraSecretKeystore.new
$ puts ks.send(:key)
"nobody-should-read-this-ever"
*yuk*
so I can just use [public] for _everything_ as well, right?
Best regards
Peter
It's true that there are many ways to bypass method scope. Ruby trusts us to do the right thing. We consider things like send() and instance_eval() to be tools. They are perhaps dangerous at times, but they are also very powerful. It's a trade-off.
If you're looking for iron-clad laws, Ruby's dynamic nature will probably not appeal to you much.
James Edward Gray II
On Oct 26, 2005, at 2:32 PM, Peter Ertl wrote:
Why is this allowed / possible?
class MyUltraSecretKeystore
private
def key
return "nobody-should-read-this-ever"
end
endks = MyUltraSecretKeystore.new
$ puts ks.send(:key)
"nobody-should-read-this-ever"
*yuk*
so I can just use [public] for _everything_ as well, right?
While it may or may not be a good idea that #send subverts access
control, your choice of example betrays a misunderstanding of the
meaning of "private".
"private" is not intended as a security measure. It's an
encapsulation technique. You'll find this is generally true in other
languages as well. You can certainly subvert "private" in C++.
"private" exists only to tell other programmers which methods they
really shouldn't be calling.
regards,
Ed
On Thu, Oct 27, 2005 at 04:32:36AM +0900, Peter Ertl wrote:
Why is this allowed / possible?
$ puts ks.send(:key)so I can just use [public] for _everything_ as well, right?
In current Ruby 1.9 you may not send private methods. I don't know
whether this is an experiment or a permanent restriction.
Regardless, you may ks.instance_eval { key } anyway, though in
this case at least you have $SAFE at your disposal.
jeremy
On Oct 26, 2005, at 12:32 PM, Peter Ertl wrote:
Why is this allowed / possible?
class MyUltraSecretKeystore
private
def key
return "nobody-should-read-this-ever"
end
endks = MyUltraSecretKeystore.new
$ puts ks.send(:key)
"nobody-should-read-this-ever"
*yuk*
so I can just use [public] for _everything_ as well, right?
not a big deal.. i pretty much enjoy the freedom of ruby!
I have years of java type safety and design pattern torture
behind me and ruby is the light at the end of the tunnel 
however, wouldn't it make sense to forbid Object#send
when using a specific taint level?
--- Ursprüngliche Nachricht ---
Von: James Edward Gray II <james@grayproductions.net>
An: ruby-talk@ruby-lang.org (ruby-talk ML)
Betreff: Re: how private is private in ruby?
Datum: Thu, 27 Oct 2005 04:38:36 +0900On Oct 26, 2005, at 2:32 PM, Peter Ertl wrote:
> Why is this allowed / possible?
>
> class MyUltraSecretKeystore
> private
> def key
> return "nobody-should-read-this-ever"
> end
> end
>
> ks = MyUltraSecretKeystore.new
>
> $ puts ks.send(:key)
>
>> "nobody-should-read-this-ever"
>>
>
> *yuk*
>
> so I can just use [public] for _everything_ as well, right?It's true that there are many ways to bypass method scope. Ruby
trusts us to do the right thing. We consider things like send() and
instance_eval() to be tools. They are perhaps dangerous at times,
but they are also very powerful. It's a trade-off.If you're looking for iron-clad laws, Ruby's dynamic nature will
probably not appeal to you much.James Edward Gray II
Edward Faulkner wrote:
While it may or may not be a good idea that #send subverts access
control, your choice of example betrays a misunderstanding of the
meaning of "private"."private" is not intended as a security measure. It's an
encapsulation technique. You'll find this is generally true in other
languages as well. You can certainly subvert "private" in C++."private" exists only to tell other programmers which methods they
really shouldn't be calling.
Exactly right.
I made an analogy the other day with the movie _Apollo 13_. Remember
when Bacon's character had been awake for many hours and was, as he
said, "a little punchy"? There was a toggle switch which would
separate the two modules (and thus doom to death the other two astro-
nauts who were spending their time in the other one). He taped a
piece of paper over it saying "NO."
That's how "private" works.
Hal
the other way to subvert private (or protected) declarations is to
subclass the class with the private methods, and declare the
superclass' private method public in the subclass.
Jeremy Kemper wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1On Oct 26, 2005, at 12:32 PM, Peter Ertl wrote:
> Why is this allowed / possible?
>
> class MyUltraSecretKeystore
> private
> def key
> return "nobody-should-read-this-ever"
> end
> end
>
> ks = MyUltraSecretKeystore.new
>
> $ puts ks.send(:key)
>
>> "nobody-should-read-this-ever"
>>
>
> *yuk*
>
> so I can just use [public] for _everything_ as well, right?In current Ruby 1.9 you may not send private methods. I don't know
whether this is an experiment or a permanent restriction.Regardless, you may ks.instance_eval { key } anyway, though in
this case at least you have $SAFE at your disposal.jeremy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (Darwin)iD8DBQFDX+CVAQHALep9HFYRAlV3AJ9BEHcb5Xmb8qRLS09A8KXJCIU4sQCfQroC
k0r75fKUoI5Z3UiE0upzDc8=
=X4SS
-----END PGP SIGNATURE-----
Hi --
On Thu, 27 Oct 2005, Peter Ertl wrote:
not a big deal.. i pretty much enjoy the freedom of ruby!
I have years of java type safety and design pattern torture
behind me and ruby is the light at the end of the tunnelhowever, wouldn't it make sense to forbid Object#send
when using a specific taint level?
There was a fairly huge thread not long ago on the matter of having
two versions of 'send', one of which would include private methods and
the other of which wouldn't. I don't think anything was decided,
except that Matz didn't like my idea of 'send' vs. 'send!'
David
--
David A. Black
dblack@wobblini.net
Edward Faulkner wrote:
>
> While it may or may not be a good idea that #send subverts access
> control, your choice of example betrays a misunderstanding of the
> meaning of "private".
>
> "private" is not intended as a security measure. It's an
> encapsulation technique. You'll find this is generally true in other
> languages as well. You can certainly subvert "private" in C++.
>
> "private" exists only to tell other programmers which methods they
> really shouldn't be calling.Exactly right.
I made an analogy the other day with the movie _Apollo 13_. Remember
when Bacon's character had been awake for many hours and was, as he
said, "a little punchy"? There was a toggle switch which would
separate the two modules (and thus doom to death the other two astro-
nauts who were spending their time in the other one). He taped a
piece of paper over it saying "NO."That's how "private" works.
That has got to be one of the best analogies I've read in a long, long time.
Hal
On 10/26/05, rubyhacker@gmail.com <rubyhacker@gmail.com> wrote:
--
===Tanner Burson===
tanner.burson@gmail.com
http://tannerburson.com <---Might even work one day...
Hi --
On Thu, 27 Oct 2005, Gene Tani wrote:
the other way to subvert private (or protected) declarations is to
subclass the class with the private methods, and declare the
superclass' private method public in the subclass.
I don't think that has any effect. You could, however, reopen the
class itself and (re)declare the methods public.
David
--
David A. Black
dblack@wobblini.net
Agreed! Though there goes our "come on, it's not exactly rocket science"
argument
martin
Tanner Burson <tanner.burson@gmail.com> wrote:
On 10/26/05, rubyhacker@gmail.com <rubyhacker@gmail.com> wrote:
>
> I made an analogy the other day with the movie _Apollo 13_. Remember
> when Bacon's character had been awake for many hours and was, as he
> said, "a little punchy"? There was a toggle switch which would
> separate the two modules (and thus doom to death the other two astro-
> nauts who were spending their time in the other one). He taped a
> piece of paper over it saying "NO."
>
> That's how "private" works.That has got to be one of the best analogies I've read in a long, long time