Access control in Ruby feels, to me, a little different to access control in other languages. In this post I’m going to talk about it, demonstrate ways around it and ultimately give my opinion on why I think access control in general is a little bit pointless.
Note: This is going to be fairly light-hearted and not-practical. If you truly need something to be private in your code there are best practices involving databases and encryption. This post just aims to demonstrate the possibilities in Ruby and have some fun with them.
Prerequisite Knowledge: Knowing what access control is will help, but I’ll
provide an explanation at the beginning of the post anyway. Basic Ruby is
required. Some of the metaprogramming stuff might be confusing but bear with it.
If you don’t know what
instance_eval does, I recommend looking it up before
reading this post.
What is access control?
Access control is the jargon used to describe whether a member variable in an object is public, private, protected or any other variation defined by the language in question. A brief overview of the generally accepted definitions of the popular three:
- Public: Accessible to all, inside and outside of the object.
- Private: Accessible only inside the object. Cannot be accessed by anything outside of methods in the object, not even inheriting objects.
- Protected: Accessible inside the object and inside any inheriting objects.
However, Ruby and its dynamic nature treats access control a little differently. I don’t want to restate anyone, and there’s a fantastic blog post that has already covered this beautifully so I’ll just link to it: Alan Skorkin on Access Control in Ruby. Please read it before continuing.
Circumventing Access Control
One of the arguments I hear, and was taught at University, is that access control stops people screwing with and invalidating the internal state of your object. So by declaring all of your attributes as private and defining getters and setters to them, you are controlling the data that goes into your object.
Take the following example:
1 2 3 4 5
It’s naive to believe that this is private in any way. It shows up when you inspect the object:
You can also straight up access it through
1 2 3
So instance variables are most certainly not private and, as far as I can tell, there’s no way to make them so.
So let’s up our game. Let’s try something a bit better and define ourselves an explicitly private method:
1 2 3 4 5 6
This time we won’t see anything revealing when we initialize an object of Foo:
And we definitely cannot call the method:
1 2 3 4 5
So on the surface it seems pretty safe. Unfortunately, using some popular Ruby metaprogramming techniques it’s very easy to access this private variable from anywhere in a program. Two examples:
Accessing private methods with
1 2 3
send method is available to every object in Ruby and simply acts as if
it’s calling a method with the same name as the symbol passed in. It doesn’t
stop for anybody, not even the
Accessing private methods with
1 2 3
instance_eval allows you to execute code as if it was written inside the
instance of the object it was called on. It, too, is available on all objects
and allows us to freely access the
secret method without so much as a whimper.
Okay. So how about we try and stop people from using these techniques to get at our private data? Look at this class:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Here we’re overriding the two methods we saw before that allowed people to get at our private method in the hope that will totally block access.
Still, this won’t protect our data:
1 2 3
remove_method method is available in all Ruby classes and will just
discard of a method definition so that people can once again get at our data.
What about if we override
class_eval as well?
class_eval is what was letting
people get into the
Foo class and remove the
send method override. Here’s
the new class with even better security:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Again, this just won’t work. There’s nothing stopping people reopening the class and just removing the method that way:
1 2 3 4 5 6 7
And I honestly can’t see a way around that one, which ends this particular branch of madness.
Another technique worth mentioning…
If you do somehow figure out how to get around all of the above things that have been mentioned, let’s not forget the following possibility:
1 2 3
It won’t tell you exactly where the secret value is and it won’t work if there are no methods defined in the class, but if the conditions are right then you’ll get output that looks like this:
Which is the relative file name and the line of the first method in that file. Ruby is an interpreted language. By necessity, the user will have your source code. It’s pointless trying to make anything private any way.
So what’s the point of access control?
The idea of access control in Ruby is to serve as a guide. If a developer marks something as private or protected, they are trying to make it clear to you that you really need to know what you’re doing if you want to play around with it. Apart from that, there is very little point of marking things as private or protected.
Even in strongly typed languages such as Java that enforce access control pretty strongly (though it is still circumventable) I think it’s pointless, if not harmful. Occasionally the developer is held back by the fact something is marked as private (a useful helper method for example) a situation I have found myself in more than once using third party libraries in the past. Sure, it makes the auto-complete list look cleaner when there are no private methods in it but sometimes it’s incredibly helpful to have access to them. I know the implications, I’m not stupid.
You’ll rarely find anything marked as private in my code. If I ever wanted to mark something as private, I would do it in a conventional way, using leading underscores, rather than trying to hide things on the top shelf so to speak.
I hoped you enjoyed this trip down the rabbit hole. If you can think of any other creative ways of getting access to code people don’t want you to access please let me know. Stretching languages is always fun and it’s a practice well worth engaging in :)
Before getting angry and telling me it’s stupid to try and hide sensitive
information in private variables, I assure you that I am well aware. The idea of
this post is to demonstrate that it’s very easy to get around the
declaration and hopefully demonstrate some cool metaprogramming techniques to
people who may not be familiar. It’s not intended to be a tutorial on how make
“truly private” methods in Ruby, I doubt such a thing is even possible.