Go to Visual Studio command prompt and type mscorcfg.msc  <Enter>.  Refer to the screen shot below.

Figure 2

When you click on the option "Microsoft .NET Framework 2.0Configuration," you should see the following dialog.

Figure 3

Right click on the Permission Sets and select New.

Figure 4

Now, enter a name for the permission set and click next.

Figure 5

From the available permissions shown in the screen shot above, select one or more permissions and set the required attributes. In our case we will choose SQLClient, File IO, User Interface and Security. Refer to the screen shots below.

Figure 6

Figure 7

Figure 8

Figure 9

Observe that we have set permissions for all the selected permissions. Now, click on finish. You should be able to see the following screen.

Figure 10

Next, go to the code groups, right click on All_Code and select New.

Figure 11

Specify a new to the new code group as shown below.

Figure 12

Select the option "Strong Name" as the condition type. Remember that at this stage you should be ready to create a strong key and compiling your project with this key. Once that is done, click the Import button to import the assembly. You will notice that the public key is copied into the box. Refer to the screen shot given below.

Figure 13

Then you need to select a permission set from the lost of the permission sets. We shall select the one we had created earlier. Here is the screen shot that illustrates the same.

Figure 14

Once that is done, you need to select the first check box in the membership group. This is because permissions will be a union for more than one set of policies. By checking the first check box, we are saying to use only the permissions that we specified.

Figure 15

Now, when you try to execute your project, you will see the following exception. This exception is thrown because you do not have permission to access the SqlClient assemblies. Here is the screen shot that illustrates this.

Figure 16

Note that we have set the read permissions to the Sample.txt file, but not the write permissions to it. When you click on the next screen, here is the output that you will see.

Figure 17

Reckoning of Permissions

We have discussed the policy levels and code groups. But, how would the run time calculate the permissions when the code belongs to multiple policies or code groups in the same policy? The run time does it in the following manner.

·         Initially, the entire All_Code group and all its child code groups are checked for any matching permissions. As said, permissions are identified by evidences.

·         Then a union of permissions is performed for those identified in various groups.

The above procedure is repeated for each policy level and the outcome of permissions at each level are then intersected.

Requesting for Permissions

You might have encountered a time when you wished to check the permissions for an assembly before actually performing any operations. For instance, you might have a small windows application that reads configuration data from the UI and creates an XML file to store that information. But at the time of saving, the assembly might have not gotten any permission on the C:, and a security exception was thrown. To handle this, CAS provides three approaches which can be applied at the assembly level using declarative syntax.

·         RequestMinimum

·         RequestOptional

·         RequestRefuse

RequestMinimum defines the permissions the code requires to execute. For example, the code below makes an attempt to write into a file. If the code does not have any permissions for writing then the assembly will not be loaded.

Listing 2

using System.IO;
using System.Security;
using System.Windows.Forms;
using System.Security.Permissions;
 
// This is a declarative security call at assembly level.
 
[FileIOPermissionAttribute(SecurityAction.RequestRefuse, "C:")]
namespace DemoApp
{
  public class MyClass 
  {
    //TODO:....
  }
}

RequestOptional defines permissions that the code can use, but is not necessarily required to execute. In this case the assembly is loaded, but if the required permissions are not set then a security exception is thrown by the run time.

RequestRefuse defines a set of permissions that you might never want to grant to the code even though the security policy allows the permissions. Suppose that you need to ensure that you want to read the files and not even accidentally write into those files, then you could use the following.

Listing 3

[assembly:FileIOPermission(SecurityAction.RequestRefuse, Write="C:")]