Singleton Pattern in .Net is not possible?

Question

Hi Guys

I have a very interesting situation , i have figured out that Singleton pattern is not all possible with .net framework (Any version)

look at this code below

namespace SingletonPattern
{
    class Singleton
    {
    private static readonly Singleton instance = new Singleton();
    private static int mcount = 0;

    private Singleton() {

        mcount += 1;
        Console.WriteLine("Creating {0} instances of Singleton Class", mcount.ToString());
    }

    public static Singleton Instance
    {
        get
        {
            return instance;
        }
    }
}

class program
{
    static void Main()
    {
        for (int i = 0; i < 1000; i++)
        {
            System.Activator.CreateInstance(Type.GetType("SingletonPattern.Singleton"), true);
        }

        Console.ReadLine();


        }
    }
}

with the help of System.activator any buddy can break singleton pattern.

so who's at risk ?

any guy who wrote some licensing component where license is implemented as a singleton pattern.

Any server based code which makes use of Singleton pattern.

Maybe I am wrong or my discovery does not make sense but i just wanna share and want to know your views?

Answer 1

It is true that this implementation of a singleton is wrong, but that doesn't mean that someone couldn't create a better singleton implementation.

Answer 2

By the same token, all private methods are not private because you can access them using reflection.

I don't see a problem with this.

Answer 3

Just because it is possible to deliberately circumvent a pattern in this way does not mean that the pattern itself is "not possible".

Answer 4

it's System.Activator class which is not foolproof, i guess and can create hazards thfor a application , i wonder why Microsoft does not think about this.

Answer 5

To use System.Activator.CreateInstance, you need high permissions. Of course if you're allowed to ignore access modifiers because the system trusts you, then you can break code that depends on consumers respecting access modifiers.

Normally, code does not usually have these permissions.

Answer 6

if you want to protect against this edge case just change private ctor:

private Singleton() { throw new ApplicationException{
     "Don't call System.Activator.CreateInstance on this class"); }

And then you'll then have to add another parameterized private ctor to actually create the singleton... perhaps with a secret parameter that only the initalizer will know how to pass... entire class would be:

class Singleton
{    
   private static readonly Singleton inst = new Singleton("MySecretWord");    
   private static int mcount = 0;   
   private Singleton(string secret)
   { if (secret != "MySecretWord")  
       throw new ApplicationException{
           "Don't call Private constructor on this class"); 
   }
   private Singleton() { throw new ApplicationException{
     "Don't call System.Activator.CreateInstance on this class"); }
  public static Singleton Instance { get  {  return inst ;  } }
}

But why go to all this trouble ? if someone wants to go to the trouble to break your singleton pattern using CreateInstance, then that's there problem, no?

Answer 7

If you are concerned about other code attempting to break this pattern, you could use something like a lock, or a semaphore or mutex,etc.. in your implementation to manage the number of instances.

...which might end up making it just a little bit more difficult, as reflection may still be used again to circumvent this...

But - with a locking mechanism, you will take a performance hit, so you have weigh the benefits..

Answer 8

I don't think design patterns are a form of security as much as a way to encourage a certain usage. If someone is going to that much trouble to work around the constraints of your design, they get what they deserve.

Answer 9

but Dale if my code is weak enough {it is not tracking the no of instances of the class.} than most of the implementations can be broken.

Answer 10

Every client-side licensing scheme can be broken.

You could work around this by throwing an exception if the counter is greater 1 - but then again, the other code could use Reflection to reset the counter. The calling code could even modify your assembly before loading it, completely removing the licensing code!

No programming language, obfuscator, etc. can completely protect you against this - if it was possible, surely game publishers would have already used it to create unbreakable copy protection!

As soon as you've got untrusted code in the same 'security zone' as your code; you've already lost.

Answer 11

Thanks Guys

For the responses and i found that .net framework is having best design and code should enforce Code Access Security whenever possible.

Write Secure Code.

Regards Saurabh