Pro CSharp 2008 And The .NET 3.5 Platform [eng]

692 CHAPTER 20 ■ FILE I/O AND ISOLATED STORAGE

Here you can see that CarLibrary.dll has been placed into the MyComputer zone, from the URL of C:\MyAsms\CarLibrary.dll, and has a specific strong name value. If you were to load assemblies from an entirely different location (such as a remote website), you would obviously see unique output. In any case, at this point simply understand that when an assembly is loaded into memory, the CLR will investigate the supplied evidence.

■Source Code The MyEvidenceViewer project is included under the Chapter 20 subdirectory.

The Role of Code Groups

Using evidence, the CLR can then place the assembly into a code group. Each code group is mapped to a security zone that has a default out-of-the-box set of security settings the CLR will use to dictate exactly what the assembly can (or cannot) do. Table 20-13 documents some of the more common code groups to be aware of, including their default assigned permission set (examined in the next section).

Table 20-13. Several Common Code Groups

The .NET Framework 3.5 SDK ships with a GUI administration tool that allows system administrators to view and tweak existing code groups or, if need be, define a brand new code group. For example, using this tool it is possible to inform the CLR that any external assembly downloaded from a particular URL (such as http://www.intertech.com) should execute within a customized security sandbox.

■Note The .NET Framework 3.5 SDK also provides a command-line tool named caspol.exe that provides the same options.

This tool can be run by double-clicking the Microsoft .NET Framework Configuration applet located under the Administrative Tools folder of your machine’s Control Panel. Once you launch this tool, you are able to configure CAS settings on three basic levels: the enterprise at large (e.g., all networked machines), the current machine, or on a per-user basis. (It is also possible to configure CAS on the application domain level as well, but this can only be done programmatically.) Figure 20-11 shows the expended nodes of the default “machine-level policy” settings for CAS on my current computer.

Again, notice that the All_Code code group (which represents all .NET assemblies) defines several zones to which an assembly can belong (My_Computer_Zone, etc.). If you were to right-click any of the nodes under the All_Code root, you would be able to activate a property page that describes further details. For example, Figure 20-12 shows the properties of the My_Computer_ Zone code group, which again represents any assembly loaded directly from the local hard drive.

Figure 20-11. The CAS-centric machine policy

Figure 20-12. Details of the My_Computer_Zone code group

If you were to click the Membership Condition tab, you would be able to determine how the CLR figured out whether a given .NET assembly should be a member of this zone. In Figure 20-13, you can see the membership condition is the rather nondescript value Zone, meaning the location at which the assembly has been loaded.

In contrast, the permission set granted to assemblies that are loaded from an external URL (outside of a company intranet) will be placed into the Internet_Zone code group, which runs under a much more restrictive set of privileges. As you can see in Figure 20-15, assemblies loaded into the Internet_Zone group are not given Full Trust permissions, but are rather assigned to a set of permissions named Internet.

Figure 20-15. Assemblies loaded from external URLs are not granted Full Trust permissions by default.

The Role of Permission Sets

As you have seen, the CLR will place an assembly into a code group based on various criteria (origin of the load, strong name, etc.). The code group in turn has a set of permissions assigned to it that are given a friendly name such as Full Trust, Internet, and so forth. Each permission set (as the name implies) is a collection of individually configured permissions that control various security settings (access to the printer, access to the file system, use of the reflection API, etc.). Using the Microsoft .NET Framework Configuration utility, you are able to view the settings for any of the default permission sets simply by selecting the View Permissions link. Figure 20-16 shows the permissions for the Internet permission set, once the View Permissions link has been clicked.

Each of these icons (File Dialog, Isolated Storage File, Security, etc.) represents a specific permission in the set, all of which can be further configured by double-clicking a given item. For example, if you were to double-click the Security permission (which is sort of a catchall permission for common security settings), you could see that if an assembly is running under the Internet_ Zone (thereby restricted by the Internet permission set), it is able to execute, but by default cannot perform a number of other basic details, such as make use of platform invocation services to call into the API of the operating system (see Figure 20-17).

696 CHAPTER 20 ■ FILE I/O AND ISOLATED STORAGE

Figure 20-16. Internet permission set

Figure 20-17. Viewing individual permissions for a permisson set

Observing CAS in Action

To illustrate a very simple example of CAS operations, we will change some default settings for the My_Computer code group and observe the results. Begin by right-clicking the My_Computer_Zone code group for your machine policy using the Microsoft .NET Framework Configuration applet to open the related property page. Next, click the Permission Set tab, and change the permission set from Full Trust to Internet (see Figure 20-18).

698 CHAPTER 20 ■ FILE I/O AND ISOLATED STORAGE

Restoring Full Trust to the My_Computer_Zone Code Group

Now, use the Microsoft .NET Framework Configuration applet to restore the Full Trust permission set to the My_Computer_Zone code group. Once you do so, you should be able to execute the

DriveInfoApp.exe without error.

■Note Obviously, when you tinker with the default CAS settings for your machine account, you could accidentally establish settings that severely cripple the execution of your applications! If you ever need to roll back to the default out-of-the-box machine policy settings, simply right-click the Machine icon under the Runtime Security Policy folder and select the Reset menu option.

That wraps up our primer of Code Access Security. Again, this introduction was not intended to provide complete coverage of this very rich API; however, you should now be in a solid position to better understand the usefulness of isolated storage.

An Overview of Isolated Storage

As mentioned, one major reason for the isolated storage API is to provide a safe sandbox where applications can read/write data, regardless of which code group they are placed into and without the need to alter the default security policies. In addition, use of this technology is ideally under a number of circumstances such as the following:

•You need to save preferences for your application for each user or forms of per-user data (DataSets, XML files, etc.).

•You are deploying a ClickOnce application that functions in a sandbox and has no access to the (unrestrained) local file system.

•You have downloaded Windows Forms controls from a URL that integrate into a web application, and they must store settings on the client machine.

•You are deploying a XAML Browser Application, or XBAP (see Chapter 28), that needs to persist data on the user’s machine.

Do be aware that if your application is using isolated storage, this does not mean that you would not also opt to store bits of data in a *.config file (such as connection strings) or place various application settings in the system registry. In fact, like any technology, isolated storage does have a few potential drawbacks. First and foremost, data placed into isolated storage is not automatically encrypted. Therefore, just like traditional IO, if you write out sensitive data (e.g., credit card information), you will need to manually encrypt (and decrypt) the information.

■Note Use of the .NET encryption APIs in not covered in this edition of the text. If you are interested in examining the details, look up the topic “Cryptographic Services” using the .NET Framework 3.5 SDK documentation.

As well, data placed into isolated storage, like any part of the file system, can be copied, moved, or deleted by the end user. However, as you will see, the types of the System.IO.IsolatedStorage namespace store data in a dynamically generated directory structure that is tucked away in a specific location of the hard drive. For this reason, it is true that most end users will have no direct encounters with their machine’s isolated storage area.

Finally, be aware that a system administrator can limit the storage size of a machine’s isolated storage quota. Thus, if your application is persisting vast amounts of data, and other applications

on the machine are also persisting vast amounts of data, there is a chance that the storage area will meet its upper limit (it is always a good idea to make use of structured exception handling techniques to gracefully handle this possibility).

The Scope of Isolated Storage

By its very nature, isolated storage will also persist data using (at very least) the current user as a level of isolation. Therefore, if you have authored a program that saves data using isolated storage, the data is persisted based on the currently logged on user. If another user logs on to the same workstation and saves data using the same application, the data is persisted into a unique location for that particular user.

In addition to user-level partitioning, isolated storage can also be set up to further isolate data based on the assembly and/or application domain identity. If you configure isolation and the user + assembly level, the application will be able to use the same store regardless of which application domain is hosting the program. In this case, the most specific piece of available evidence (such as a strong name) will be used to create the store name. This would allow the end user to have multiple instances of the program running on a single machine, where each instance is “pointing” to the same store (see Figure 20-20).

Figure 20-20. User and assembly-level isolation

On the other hand, if you configure a user + assembly + application domain isolation level, the application domain is also taken into consideration. In addition to the most specific form of assembly evidence, the most specific form of AppDomain evidence (typically Site) will be used to build the store. With this approach, even if the same assembly is used by unique AppDomains, the data is maintained in separate stores (see Figure 20-21).

Isolated storage can also be used to build roaming profiles. The roaming scope allows users to log on to unique workstations and obtain the same application data. In this case, the storage data is persisted to a network location and downloaded on demand when a user logs on to a given workstation. We will not be examining this aspect of isolated storage, so consult the .NET Framework 3.5 SDK documentation if you are interested.

700 CHAPTER 20 ■ FILE I/O AND ISOLATED STORAGE

Figure 20-21. User, assembly, and application domain-level isolation

Locating Isolated Storage

Again, isolated storage is nothing more than a dedicated part of a .NET machine’s file system, so to this end it is no different from C:\Windows, C:\Program Files, or any other directory on your disk. However, the exact location of isolated storage will differ based on your operating system. On a Vista machine, you can find the root location of a given store under

C:\Users\<user>\App Data\Local\IsolatedStorage

On a Windows XP machine, the root location for isolated storage can be found under

C:\Documents and Settings\<user>\Local Settings\Application Data\IsolatedStorage

Beneath this root, you will find a number of (completely unpronounceable) subdirectories that are created and maintained by the isolated storage API. Consider Figure 20-22, which shows the storage location on my current Vista machine.

Again, you do not need to worry about deciphering the names of these folders, nor do you need to specify their names programmatically when creating stores for your users. These names are generated based on user identity and the required assembly and/or application domain evidence. When gathering evidence for assemblies and AppDomains, the CLR evaluates in this order (most specific to least):

•Publisher certificate

•Strong name

•URL

•Site

•Zone

Figure 20-22. Isolated storage on a Vista machine

Interacting with Isolated Storage Using storeadm.exe

The .NET Framework 3.5 SDK ships with a command-line utility named storeadm.exe, which can be used to interact with the current storage system on a given .NET machine. Using this tool, you are able to view the current stores for the logged in user (via the /list option) and completely delete all storage for the current user (by specifying /remove). Consider Figure 20-23, which shows the output resulting from the /list option.

As you can glean from the previous figure output, this tool also displays the level of isolation (assembly, application domain) and the forms of evidence used to establish the store. What this tool does not display is the actual contents of the files placed in a given store. To do so, you will have to locate the generated store location using the Windows Explorer or read in the data programmatically.