Reconsider Activator.CreateInstance

Topics: Argotic.Extensions, Request For Comments (RFC)
Developer
Apr 6, 2008 at 12:34 PM
Hi,

Please reconsider the use of this method as it requires System.Security.Permissions.SecurityPermission which isn't very nice for shared hosting users.

Gary
Coordinator
Apr 6, 2008 at 5:02 PM
Gary,

I think you are referring to this call within the Argotic.Extensions assembly:
ISyndicationExtension extension = Activator.CreateInstance(type) as ISyndicationExtension;

There were some major performance/maintainability issues with passing object instances around with the previous implementation of syndication extensions, which caused to move to use type based activation. The security permissions as I understand them are:
  • SecurityPermission (SecurityPermissionFlag.UnmanagedCode)
    • For the ability to call unmanaged code when creating an instance of a delegate.
  • ReflectionPermission (ReflectionPermissionFlag.RestrictedMemberAccess)
    • For accessing a nonpublic type when the grant set of the nonpublic type is restricted to the caller's grant set, or to a subset thereof.
  • ReflectionPermission (ReflectionPermissionFlag.MemberAccess)
    • For accessing nonpublic types regardless of their grant sets.

The .NET documentation also notes that:
"Starting with the .NET Framework version 2.0 Service Pack 1, this method can be used to access nonpublic types if the caller has been granted ReflectionPermission with the ReflectionPermissionFlag.ReflectionEmit flag and if the grant set of the assembly that contains the nonpublic types is restricted to the caller’s grant set, or to a subset thereof."

I will review the documentation on Security Considerations for Reflection, to see if there is a way to reduce/remove the permission requirements. For now I have removed the SecurityPermission(SecurityAction.InheritanceDemand, Flags = SecurityPermissionFlag.UnmanagedCode) demand from the SyndicationExtension abstract base class, as there are no explicit calls to unmanaged code. This leaves just a ReflectionPermission demand, and furthermore, on the .NET 3.5 targeted version of the SyndicationExtension abstract base class I have reduced the permission demand to just be ReflectionPermission(SecurityAction.InheritanceDemand, Flags = ReflectionPermissionFlag.ReflectionEmit).

Hopefully the ReflectionPermission demand will not be too restrictive for shared hosting users.

- Brian
Developer
Apr 6, 2008 at 10:35 PM
Hi Brian,

Thanks for the fast reply I can understand the issues with changing it. I am not sure how many people use shared hosting for asp.net projects.

To get around it I removed the request for the ReflectionPermission and SecurityPermission and created the ISyndicationExtension instances hardcoded. It is not as tidy and isn't very extensible but it does work on shared hosting in medium trust.



Gary
Coordinator
Apr 7, 2008 at 5:10 PM
Gary,

If you have time, can you see if leaving just the ReflectionPermission demand allows you to use the extensions in your shared hosting environment? If it is still an issue, I will try to provide an alternative way to add/remove supported extensions. If you have any ideas or recommendations, I am always open, as I want to try to handle the shared hosting scenario.
Apr 15, 2008 at 7:32 PM
Hi,
ReflectionPermission is causing fits at my shared host. If I remove them from the classes, everything works fine without permission errors. I write a DotNetNuke (ASP.NET) module that uses Activator.CreateInstance for creating it's plugins without problem, and it's running on several different shared hosting providers.
The host I'm working with at the moment is JodoHost, and they have the following defined in machine.config if it helps:

<SecurityClass Name="ReflectionPermission" Description="System.Security.Permissions.ReflectionPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>

<IPermission
class="ReflectionPermission"
version="1"
Flags="ReflectionEmit"
/>

Thanks,
Mike
Coordinator
Apr 15, 2008 at 8:40 PM
Mike,

I had added reflection demands based on the Remarks and Permissions sections of the Activator.CreateInstance(Type) documentation, but the demand isn't necessary unless attempting to access a nonpublic type. I have created the Remove ReflectionPermission demands to improve support for shared hosting environments work item to track the change request to remove the reflection security demand(s), and will note in the framework documentation that syndication extensions should be exposed as publicly accessible types. Hopefully this will alleviate the troubles shared hosting developers are having. I have also noted in the work item the configuration settings you mentioned, as that may also provide a possible workaround for some shared hosting situations.
Apr 19, 2008 at 11:37 AM
Thanks for the change Brian! I'm always happy when I don't have to maintain my own source. And thanks for all the great work, this is a wonderful library.
Thanks,
Mike
Coordinator
Apr 19, 2008 at 4:39 PM
Mike,

Thanks for the positive feedback, it is what keeps me going. I will try to provide an interim release that includes this fix in the near future.
Coordinator
Jul 1, 2008 at 6:12 PM
Created work item #10001 to address this issue, this feature will be available in the next release.