Warning: Heavy technical content following
On Friday I tried to build a piece of software which is usually maintained by a colleague who’s on vacation right now. During build a tool is called which always crashed with a
SecurityException. The reason was easy to find. My system’s executable search path contained a folder residing on a server in our network and the tool was xsd.exe, a managed code program. Per default managed code running from a network share gets much less permissions than running from a local hard disk. The technology behind this in the Microsoft .NET framework is called
Code Access Security (CAS). It’s one of the most interesting features of the framework and has no counterpart in the unmanaged world. Until then I only knew that it's there and how it worked in principle, but nothing more.
To solve my problem I could just change the path and run the tool from my local hard disk. But I thought that it would be better to just trust all code coming from that network share, because it’s our main development server on our internal network where only a few people are allowed to install software. And it could be a good learning experience, too.
Code Access Security is defined via policies which can be configured by using a command-line tool called caspol.exe. In addition to that, the Microsoft .Net Framework SDK installs a Microsoft Management Console (MMC) snap-in called “.Net Framework 2.0 Configuration” which is able to configure CAS policy, too. I used the configuration tool and defined a new code group, which grants code stemming from our development server “FullTrust”. FullTrust is a named set of permissions posing no restrictions at all and it’s the same locally started programs get.
It didn’t work.
The configuration tool has a nice feature called “Evaluate Assembly” which shows the CAS permissions granted to a program. It showed that my configuration was correct. However when started, it still threw the security exception. Further examination showed that the standard permission for code running in the intranet zone is has been applied.
I tried it by using the executable’s strong name instead of the URL for the code group. No luck. I tried the same on my notebook running Windows Vista, too. It worked perfectly. I tried it on a Windows XP test system. It worked there, too. Now I used the command-line caspol.exe instead. The command-line parameters are not that complicated and google revealed some good examples. I will not explain it here, just mention the commandline I used:
Caspol –m –ag 1.2 –url \\server\share\* FullTrust
Same results: Works on my Vista notebook, the XP test system, but not on my development machine. I’ve built a small C# test program in case xsd.exe did something weird. Same results. Now I tried a Windows Server 2008 Beta system, because it was easily available running as VMWare guest. No luck, either.
Only then I recognized a pattern. Both my development machine and the W2k8 beta are 64bit operating systems, the other ones are 32bit. It worked in 32bit, but not on 64bit. I should have recognized that much, much earlier :-( It turns out that on 64bit Windows you get a 64bit .Net Framework version which has different CAS polices for 32bit and 64bit. There’s a folder named
C:\windows\Microsoft.Net\Framework64\v2.0.50727
It contains a 64bit version of caspol.exe. The caspol.exe I had in my path and the .Net Framework 2.0 Configuration Tool both set the 32bit policy. Xsd.exe is a pure managed code assembly. When started on my 64bit system the .Net JIT compiler generates 64bit code and the 64bit CAS policy applies, but I always changed the 32bit policy.
Problem solved. And now I know much more about code access security, how the policies are defined and applied, how I can check for CAS permissions in my code and how I can use attributes to specify the permissions a program requires.