Just some quick info for those struggling with the same problems.
When i google for this almost all answers predate the .net 3.0 framework. Everybody knows that 3.0 are a set of libraries that extend 2.0. what i missed was that 3.5 uses the same core assemblies as 2.0 including the same security settings. This means you still use the CasPol installed from the 2.0 to set full trust in 3.5. Be aware thought that you’ll need to run it for the 32-bit version and 64-bit version separately.
There is a nice post on how to do this from the .net security blog from which I included the next fragment:
since network shares by default only get localintranet permissions, it's relatively common to want to use CasPol to fully trust some shares that you control and know are safe. However, CasPol syntax being what it is, the command to do this isn't immediately obvious. if i wanted to trust everything on the share \\shawnfa-srv\tools, the command:
caspol.exe -m -ag 1.2 -url file://\\ShawnFa-Srv/Tools/* FullTrust
would setup the policy to do what i needed. lets break down this command:
- -m - modify the machine level of the policy. this is needed, since the machine level is where all of the default policy lives. on nt platforms it's also the default level that CasPol works with, however on Win9x, CasPol will default to the user level, so putting -m in the command line explicitly tells CasPol to use the correct level.
- -ag 1.2 - add a code group under group 1.2. in the default policy, group 1.2 is the localintranet group, so the new code group that we're creating will only be checked if the file comes from the intranet.
- -url file://\\ShawnFa-Srv/Tools/* - The membership condition for the new code group should be a UrlMembershipCondition, and it should match anything with a URL that starts with file://ShawnFa-Srv/Tools, meaning that any file on the \\ShawnFa-Srv\Tools share will match this code group.
- fulltrust - the permission set to grant assemblies that match the code group. in this case, fulltrust.
Executing the above command will give you a yes/no confirmation prompt which you can suppress by adding the –pp off switch. Now it’s perfectly usable in scripts.
I kept wondering about 2 things:
- what if the mapped folder was included in the trusted group?
- where does it store these settings?
Get the code groups.
To get the right -ag argument for the trusted group call:
which will give you something like this:
Microsoft (R) .NET Framework CasPol 2.0.50727.3053
Copyright (c) Microsoft Corporation. All rights reserved.
Security is ON
Execution checking is ON
Policy change prompt is ON
Level = Machine
Code Groups:
1. All code: Nothing
1.1. Zone - MyComputer: FullTrust
1.1.1. StrongName - 002400000...: FullTrust
1.1.2. StrongName - 000000000...: FullTrust
1.2. Zone - Intranet: LocalIntranet
1.2.1. All code: Same site Web
1.2.2. All code: Same directory FileIO - 'Read, PathDiscovery'
1.3. Zone - Internet: Internet
1.3.1. All code: Same site Web
1.4. Zone - Untrusted: Nothing
1.5. Zone - Trusted: Internet
1.5.1. All code: Same site Web
Success
From this output we now know that we need to use 1.5 as an –ag argument to FullTrust a path from the Trusted group.
Where is it stored?
The security information is stored in the security.config file (duh) in the following location:
%WINDIR%\Microsoft.NET\Framework\v2.0.50727\CONFIG
Our example inserts the following xml under the Trusted codegroup element:
<CodeGroup class="UnionCodeGroup" version="1" PermissionSetName="FullTrust">
<IMembershipCondition class="UrlMembershipCondition" version="1" Url="file://\\ShawnFa-Srv/Tools/*"/>
</CodeGroup>
If you don’t want the settings removed by a call to:
You can copy the security.config to security.config.default