Assembly: mscorlib (in mscorlib.dll)
[SerializableAttribute] [ComVisibleAttribute(true)] public ref class RegistryPermission sealed : public CodeAccessPermission, IUnrestrictedPermission
/** @attribute SerializableAttribute() */ /** @attribute ComVisibleAttribute(true) */ public final class RegistryPermission extends CodeAccessPermission implements IUnrestrictedPermission
SerializableAttribute ComVisibleAttribute(true) public final class RegistryPermission extends CodeAccessPermission implements IUnrestrictedPermission
RegistryPermission describes protected operations on registry variables. Registry variables should not be stored in memory locations where code without RegistryPermission can access them. If the registry object is passed to an untrusted caller it can be misused.
The allowed registry access types are defined by RegistryPermissionAccess. If more than one type of access is desired, they can be combined using the bitwise OR operation as shown in the code sample that follows.
Registry permission is defined in terms of canonical absolute paths; checks should always be made with canonical pathnames. Key access implies access to all values it contains and all variables under it.
RegistryPermission grants permission for all paths to a key, including both HKEY_CURRENT_USER and HKEY_USERS. To Deny access to a key, you must Deny all possible paths to the key. For example, to Deny access to HKEY_CURRENT_USER\Software\Microsoft\Cryptography, you must Deny HKEY_CURRENT_USER\Software\Microsoft\Cryptography, HKEY_USERS\.......\Software\Microsoft\Cryptography and any other path that you can use to access the key. A better technique to deal with multiple paths is to use a combination of PermitOnly and Deny. For more information on this subject and the use of PermitOnly with Deny, see "Canonicalization Problems Using Deny" in Using the Deny Method.
In the following code example, the RegistryPermissionf represents permission to read the values from the CentralProcessor key. Read and Write are RegistryPermissionAccess enumeration values.
RegistryPermission^ f = gcnew RegistryPermission( RegistryPermissionAccess::Read, "HKEY_LOCAL_MACHINE\\HARDWARE\\DESCRIPTION\\System\\CentralProcessor\\0" );
RegistryPermission f = new RegistryPermission(RegistryPermissionAccess.Read, "HKEY_LOCAL_MACHINE\\HARDWARE\\DESCRIPTION\\" + "System\\CentralProcessor\\0");
The following code example adds permission to read from and write to the FloatingPointProcessor key to the RegistryPermissionf.
f->AddPathList( (RegistryPermissionAccess) (RegistryPermissionAccess::Write | RegistryPermissionAccess::Read), "HKEY_LOCAL_MACHINE\\HARDWARE\\DESCRIPTION\\System\\FloatingPointProcessor\\0" );
f.AddPathList(RegistryPermissionAccess.Write | RegistryPermissionAccess.Read, "HKEY_LOCAL_MACHINE\\HARDWARE\\" + "DESCRIPTION\\System\\FloatingPointProcessor\\0");
The RegistryPermissionf now represents the permission to read from the CentralProcessor key and to read from and write to the FloatingPointProcessor key.
The following code example shows the behavior of the RegistryPermission class methods.
The code example is intended to show the behavior of the methods, not to demonstrate their use. In general, the methods of permission classes are used by the security infrastructure; they are not typically used in applications. Generally, only the constructors are used in application code. The created instance validates or controls resource access by using inherited CodeAccessPermission methods such as Demand.
Windows 98, Windows Server 2000 SP4, Windows Millennium Edition, Windows Server 2003, Windows XP Media Center Edition, Windows XP Professional x64 Edition, Windows XP SP2, Windows XP Starter EditionThe Microsoft .NET Framework 3.0 is supported on Windows Vista, Microsoft Windows XP SP2, and Windows Server 2003 SP1.