Information
The topic you requested is included in another documentation set. For convenience, it's displayed below. Choose Switch to see the topic in its original location.

FileIOPermission Class

Controls the ability to access files and folders. This class cannot be inherited.

Namespace:  System.Security.Permissions
Assembly:  mscorlib (in mscorlib.dll)

[SerializableAttribute]
[ComVisibleAttribute(true)]
public sealed class FileIOPermission : CodeAccessPermission, 
	IUnrestrictedPermission

This permission distinguishes between the following four types of file IO access provided by FileIOPermissionAccess:

  • Read: Read access to the contents of the file or access to information about the file, such as its length or last modification time.

  • Write: Write access to the contents of the file or access to change information about the file, such as its name. Also allows for deletion and overwriting.

  • Append: Ability to write to the end of a file only. No ability to read.

  • PathDiscovery: Access to the information in the path itself. This helps protect sensitive information in the path, such as user names, as well as information about the directory structure that is revealed in the path. This value does not grant access to files or folders represented by the path.

NoteNote:

Giving Write access to an assembly is similar to granting it full trust. If an application should not write to the file system, it should not have Write access.

All these permissions are independent, meaning that rights to one do not imply rights to another. For example, Write permission does not imply permission to Read or Append. If more than one permission is desired, they can be combined using a bitwise OR as shown in the code example that follows. File permission is defined in terms of canonical absolute paths; calls should always be made with canonical file paths.

FileIOPermission describes protected operations on files and folders. The File class helps provide secure access to files and folders. The security access check is performed when the handle to the file is created. By doing the check at creation time, the performance impact of the security check is minimized. Opening a file happens once, while reading and writing can happen multiple times. Once the file is opened, no further checks are done. If the object is passed to an untrusted caller, it can be misused. For example, file handles should not be stored in public global statics where code with less permission can access them.

FileIOPermissionAccess specifies actions that can be performed on the file or folder. In addition, these actions can be combined using a bitwise OR to form complex instances.

Access to a folder implies access to all the files it contains, as well as access to all the files and folders in its subfolders. For example, Read access to C:\folder1\ implies Read access to C:\folder1\file1.txt, C:\folder1\folder2\, C:\folder1\folder2\file2.txt, and so on.

Caution noteCaution:

Unrestricted FileIOPermission grants permission for all paths within a file system, including multiple pathnames that can be used to access a single given file. To Deny access to a file, you must Deny all possible paths to the file. For example, if \\server\share is mapped to the network drive X, to Deny access to \\server\share\file, you must Deny \\server\share\file, X:\file and any other path that you can use to access the file. A better technique to deal with multiple paths is to use a combination of PermitOnly and Deny. In the above example you can PermitOnly \\server\share, then Deny \\server\share\file, eliminating alternate paths completely. For more information on this subject and the use of PermitOnly with Deny, see "Canonicalization Problems Using Deny" in Using the Deny Method.

NoteNote:

Paths of the form \\server\share\bogusfolder\..\file are converted into the canonical form \\server\share\file by the security system so you only need to Deny the canonical path, \\server\share\file, and do not need to account for the syntactical variations that can be used to specify the same path. The dot operator (.) can appear singly, in multiples, or in combination with trailing blank characters. Blanks are ignored when following the dot operator. A single dot, such as in the address C:\temp\test\.\test.txt is ignored, resulting in an address of C:\temp\test\test.txt. Multiple dot operators are treated as a "..", meaning the immediately preceding directory is skipped. For example, the address C:\temp\test\.... \test.txt results in the path C:\temp\test.txt.

NoteNote:

Deny is most effective when used with the Windows NTFS file system. NTFS offers substantially more security than FAT32. For details on NTFS, see the Windows documentation.

The following examples illustrate code that uses FileIOPermission. After the following two lines of code, the object f represents permission to read all files on the client computer's local disks. The code example then demands the permission to determine whether the application has permission to read the files.

FileIOPermission f = new FileIOPermission(PermissionState.None);
f.AllLocalFiles = FileIOPermissionAccess.Read;
try
{
    f.Demand();
}
catch (SecurityException s)
{
    Console.WriteLine(s.Message);
}

After the following two lines of code, the object f2 represents permissions to read C:\test_r and read and write to C:\example\out.txt. Read and Write represent the file/folder permissions as previously described. After creating the permission, the code demands the permission to determine whether the application has the right to read and write to the file.

FileIOPermission f2 = new FileIOPermission(FileIOPermissionAccess.Read, "C:\\test_r");
f2.AddPathList(FileIOPermissionAccess.Write | FileIOPermissionAccess.Read, "C:\\example\\out.txt");
try
{
    f2.Demand();
}
catch (SecurityException s)
{
    Console.WriteLine(s.Message);
}

System.Object
  System.Security.CodeAccessPermission
    System.Security.Permissions.FileIOPermission

Any public static (Shared in Visual Basic) members of this type are thread safe. Any instance members are not guaranteed to be thread safe.

Windows 7, Windows Vista, Windows XP SP2, Windows XP Media Center Edition, Windows XP Professional x64 Edition, Windows XP Starter Edition, Windows Server 2008 R2, Windows Server 2008, Windows Server 2003, Windows Server 2000 SP4, Windows Millennium Edition, Windows 98

The .NET Framework and .NET Compact Framework do not support all versions of every platform. For a list of the supported versions, see .NET Framework System Requirements.

.NET Framework

Supported in: 3.5, 3.0, 2.0, 1.1, 1.0

Community Additions

Show:
© 2014 Microsoft