tea time with meowkins

SharePoint Custom CAS Policies – Grant ALL of the Permissions You Need

I have been learning SharePoint from the ground up recently, and one of the hardest problems I have come across is deploying a custom Code Access Security (CAS) policy with my solution package. I'll explain the problem that I encountered, and how I solved it.

First, I started off with an extremely simple web part that did absolutely nothing. I created a solution package with no CAS policy in it, installed it on WSS, and deployed it to my test site. Everything worked just fine; I was able to view my web part in the gallery, and add it to web part pages.

Then I added a CodeAccessSecurity node to my solution manifest. In the policy, I gave my web part the SharePointPermission so that it could access the object model. The install went fine, but after the solution was deployed, I got "System.Security.Policy.PolicyException: Execution permission cannot be acquired." I was very confused because in my mind, my CAS policy should have been granting me an additional permission, not removing any permissions. Moreover, I was not even making any privileged calls, the web part was unchanged and did absolutely nothing.

After asking a lot of questions, reading a lot of articles, and then analyzing the changes in my trust configuration files, I finally discovered that when I added the custom CAS policy, it was granting the SharePointPermission, but it was only granting the SharePointPermission. I then added all of the minimum permissions needed to run the web part in the first place, and then everything worked fine.

So, when you create a custom CAS policy, be sure to include ALL of the permissions that you need, not just the additional permissions.

UPDATE: Below is an example of my CodeAccessSecurity node.  It's been a long time since I wrote this and things have changed, but basically I had to add the basic permissions, AspNetHostingPermission, SecurityPermission, and WebPartPermission.

  <CodeAccessSecurity>
    <PolicyItem>
  <PermissionSet class="NamedPermissionSet" version="1" Description="Permissions for ArrowWebParts">
    <IPermission class="AspNetHostingPermission" version="1" Level="Minimal" />
    <IPermission class="SecurityPermission" version="1" Flags="Execution" />
    <IPermission class="WebPartPermission" version="1" Connections="True" />
    <IPermission class="System.Security.Permissions.FileIOPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Unrestricted="true" />
  </PermissionSet>
  <Assemblies>
    <Assembly Name="ArrowWebParts"/>
  </Assemblies>
    </PolicyItem>
  </CodeAccessSecurity>

High Speed Problem Solving

Here is one of the best tips I've ever heard, "Drill down and figure out what the challenge really entails". I got this out of a white paper about Enterprise Content Management, but it applies to software engineering and really any problem. As the paper stated; when trying to make a decision people often become paralyzed by a fear of making a mistake. To avoid being a victim of this fear sit down and figure out what your problem entails and what needs to happen to solve the problem.

So how do you actually go about figuring out what a challenge entails? For this I go to Steve Maguire, author of Debugging The Development Process. As Steve suggests in his book, when you're working on a software problem you should begin by writing down your goals, and follow up by writing down the tasks that will solve those goals.

I used to think that writing down your goals wasn't that important – obviously, if you already knew your goals you shouldn't need to document them. What I learned is that writing down your goals helps reveal what you might have missed; it can also highlight the minimal requirements necessary for solving your problem. With that, you just need to decide on what steps you'll take to solve that problem – the tasks that need to be done to realize your goals

Writing your tasks takes only a fraction of the time you'll spend implementing your solution, and it streamlines the work you do to solve the problem. If you don't have a set of tasks to follow, then you will have to figure out over and over again what to do next. Without having written your goals and tasks down you'll worry that you're not working in the most efficient manner – paralysis again. Write your tasks down to fight paralysis with confidence!

One caveat – don't get stuck planning every little detail from the start, that just leads to more paralysis. Write the steps to get the first major part of the problem solved. Sometimes it helps to write some of the next major problem's tasks as well, just to make sure that you do the first part most efficiently. Then, just get going on that first chunk of the solution. This process works very well because you feel confident about what you are doing (which makes sense since you did plan this out), and you rapidly identify all the little details that also need to be taken care of.