CSharpCodeProvider uses obsolete Assembly.Load method which takes permission information from assembly instead of appdomain

CSharpCodeProvider uses obsolete Assembly.Load method which takes permission information from assembly instead of appdomain by Anonymous12345999

Closed

as Won't Fix Help for as Won't Fix

Type:	Bug
ID:	535189
Opened:	2/21/2010 7:14:52 PM
Access Restriction:	Public

Workaround(s)

view

User(s) can reproduce this bug

The problem occurs when using the Microsoft.CSharp.CSharpCodeProvider type (located in System.dll) to compile source on the fly and generate new assemblies in memory. When CompilerParameters.GenerateInMemory is set to true, the CompileAssemblyFromSource method eventually calls down to Assembly.Load(byte[], byte[], Evidence), which has been obsoleted in .NET 4.

The documentation for that method states that when a null is passed for the Evidence, it will take the security permissions from the calling application domain. In fact, it takes the security permissions from the calling Assembly.

Now, I cannot use GenerateInMemory in a separate sandboxed AppDomain because no matter what permissions I give to the sandboxed domain the newly compiled assembly will bypass them and take those of the parent Assembly. At the very least, the documentation for the Assembly.Load method is incorrect.

Details (expand)

English

.NET Framework 4 Release Candidate

Windows 7

English

Run the attached program.

<PermissionSet class="System.Security.PermissionSet"
version="1">
<IPermission class="System.Security.Permissions.EnvironmentPermission, mscorlib,
Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
version="1"
Unrestricted="true"/>
<IPermission class="System.Security.Permissions.FileIOPermission, mscorlib, Vers
ion=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
version="1"
Unrestricted="true"/>
<IPermission class="System.Security.Permissions.IsolatedStorageFilePermission, m
scorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
version="1"
Unrestricted="true"/>
<IPermission class="System.Security.Permissions.ReflectionPermission, mscorlib,
Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
version="1"
Flags="RestrictedMemberAccess"/>
<IPermission class="System.Security.Permissions.SecurityPermission, mscorlib, Ve
rsion=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
version="1"
Flags="UnmanagedCode, Execution"/>
</PermissionSet>

<PermissionSet class="System.Security.PermissionSet"
version="1">
<IPermission class="System.Security.Permissions.EnvironmentPermission, mscorlib,
Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
version="1"
Unrestricted="true"/>
<IPermission class="System.Security.Permissions.FileIOPermission, mscorlib, Vers
ion=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
version="1"
Unrestricted="true"/>
<IPermission class="System.Security.Permissions.IsolatedStorageFilePermission, m
scorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
version="1"
Unrestricted="true"/>
<IPermission class="System.Security.Permissions.ReflectionPermission, mscorlib,
Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
version="1"
Flags="RestrictedMemberAccess"/>
<IPermission class="System.Security.Permissions.SecurityPermission, mscorlib, Ve
rsion=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
version="1"
Flags="UnmanagedCode, Execution"/>
</PermissionSet>

Press any key to continue . . .

File Name	Submitted By	Submitted On	File Size
Test.zip (restricted)	Anonymous12345999	2/21/2010	-

Posted by Microsoft on 3/25/2010 at 11:55 AM

Thanks for reporting this issue - the fix you're looking for would require API additions in the CodeDOM space, which is technically a feature. As such, I'll be logging this request as a CodeDOM feature proposal for the next version of the .NET Framework (and closing this item).

Thank you again for your feedback.

Andrew Dai
Program Manager, Common Language Runtime

Posted by Anonymous12345999 on 3/23/2010 at 9:12 AM

OK, that's fine, I can use the workaround for now. In fact I've been using it since I filed this issue.

Thanks for your help.

Posted by Microsoft on 3/23/2010 at 9:07 AM

Sorry, Mike, I pasted the wrong text. :-( I've reactivated the bug and assigned it to development. I can't say what the chances are of a service pack release. This seems low impact to me, but I don't make those decisions. I can say that the feature is viewed as reasonable and useful.

Glenn

Posted by Microsoft on 3/23/2010 at 9:01 AM

The workaround in .NET Framework version 4 is to compile the assembly to disk, instead of in memory. When the on-disk assembly is subsequently loaded into the application domain, it gets the trust level of the application domain.

Posted by Anonymous12345999 on 3/22/2010 at 10:07 PM

Yes, that would be good. Any chance on this making it the next service pack?

Posted by Microsoft on 3/22/2010 at 9:09 PM

Mike -- It doesn't look like you can do this with an in-memory assembly, because there's no way to create one without loading it. The workaround for now is to generate an assembly on disk. When you load that assembly into the application domain, it's loaded with the application domain's security.

Being able to specify that the security for in-memory assembly should come from the application domain rather than from the generating assembly is a very reasonable and low-cost feature request. Do you want to turn this bug into a request for that, in a future release?

Glenn

Posted by Microsoft on 3/19/2010 at 3:46 PM

You're quite right. This was handed off to me as a doc bug, and I was just looking at that aspect of it. Let me see what I can find out.

Glenn

Posted by Anonymous12345999 on 3/19/2010 at 3:10 PM

This doesn't help me with my original issue though, which is that generated executables can't be loaded into partial trust app domains because they bypass any security restrictions that may exist in them.

Posted by Microsoft on 3/19/2010 at 2:03 PM

Thanks for pointing this out, Mike! As you surmised, the documentation was incorrect. If you pass null Evidence, the evidence of the calling assembly is used, just as in the .NET Framework 3.5. We have updated the documentation; the correction will appear on MSDN in the near future.

Thx,

Glenn

Posted by Microsoft on 2/22/2010 at 7:05 PM

Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)