Code-access security permissions are evaluated independent of application role-based security permissions. To illustrate the relationship between the two types of security, let’s use an example of attempting to take luggage on an airplane. You get to choose the size, shape, and color of the luggage you want to take on a trip. For example, suppose you choose to take a big, yellow suitcase on a business trip. Because the suitcase contains important documents, you decide to carry it with you on the airplane. Your choice of what you want to do with your suitcase ends as soon as you get to airport security. You find that after much force and ingenuity you can’t cram your suitcase through the tiny opening into the X-ray machine. Security personnel quickly step in and point out that because of size restrictions you are not permitted to carry your suitcase onto the airplane. You pull out your business card, present it to the security guard, and explain that you are the president of an important software start-up company. This only serves to infuriate the security guard, who promptly hauls you and your luggage back to the lobby. Defeated, you check in your suitcase at the check-in counter. Your role as president of an important company did nothing to change or preempt the rules that apply to everybody.

Code-access security controls your code much like airport security controls what is allowed to be carried on board an airplane. For example, if your application is not permitted to create a file on disk, the code-access security system will refuse to allow your application to write to disk. A security exception will occur and your application will be halted much like the passenger who is halted and sent back from the airport security checkpoint. The operation will not be allowed no matter who is granted permission by your application’s role-based security system to save the file to disk—even if that person, the president of an important start-up company, was granted the permission by your role-based security model.

It’s possible to make exceptions to the rules. For example, if the head of the United Nations wanted to pass a big, yellow suitcase through security, an exception could be made to allow him to pass through. See Chapter 10 for more information on modifying and deploying security policy updates.

OS Security Restrictions Preempt Everything

Operating System (OS) security restrictions define the final set of permissions your application will need to anticipate and contend with. For example, you might define a role in your application, such as account manager, and give that role permission to save management reports to disk. In addition, your application, from a code-access standpoint, might be granted full access rights to perform Visual Basic .NET operations, such as Print #1 to write a management report file to disk. However, depending on where the file is saved on the disk, the operating system might deny the operation. If the account manager attempts to save to a file folder she does not have access to—based on operating system file-folder permissions—the operation will be denied and an error will be generated when the code is executed. Figure 3-1 illustrates how an attempt to perform some action, such as writing to a file, must pass through several security checks. Microsoft Windows security gives the final thumbs-up or thumbs-down on whether to perform the attempted action.

Figure 3-1. An attempt to perform an action must pass through several security checks

In terms of code-access security, what are determining factors in what your code is allowed to do? You might be surprised to find that your Visual Basic .NET application that runs fine on your local computer terminates with a security exception when deployed and run from a server or from the Internet. We’ll see in the next section that the actions your Visual Basic .NET code is allowed to perform are largely determined by the environment in which your code is run.