Overriding Security Checks
Normally, a security check examines every caller in the call stack to ensure that each caller has been granted the specified permission. However, you can override the outcome of security checks by calling Assert, Deny, or PermitOnly on an individual permission object or a permission set object. Depending on which of these methods you call, you can cause the security check to succeed or fail, even though the permissions of all callers on the stack might not have been checked.
.gif "Important note") Important |
|---|
In the .NET Framework version 4, runtime support has been removed for enforcing the Deny and RevertDeny permission requests. These requests should not be used in code that is based on the .NET Framework 4 or later. For more information about this and other changes, see Security Changes in the .NET Framework 4. |
Every time one method calls another method, a new frame is generated on the call stack to store information about the method being called. (Using constructors and accessing properties are considered method calls in this context.) Each stack frame includes information about any calls the method makes to Assert, Deny, or PermitOnly. If a caller uses more than one Assert, Deny, or PermitOnly in the same method call, the runtime applies the following processing rules, which can affect override behaviors:
If, during the stack walk, the runtime discovers more than one override of the same type (that is, two calls to Assert) in one stack frame, the second override causes an exception to be thrown.
When different overrides are present in the same stack frame, the runtime processes these overrides in the following order: PermitOnly, then Deny, and finally Assert.
To replace an override, first call the appropriate revert method (for example, RevertAssert) and then apply the new override.
Note
Stack-walk overrides should never be made in a class constructor because class constructor code is not guaranteed to execute at any particular point or in any particular context. Because the state of the call stack in a class constructor is not well defined, stack walk overrides placed in constructors can produce unexpected and undesired results.
Application developers do not usually need to use Assert, Deny, or PermitOnly, and component and class library developers rarely need to use them. However, security overrides are appropriate in some situations, which are described in the Assert, Deny, and PermitOnly topics.
Note
If you perform an override (Deny, Assert, or PermitOnly), you must revert the permission before you can perform the same kind of override in the same stack frame (that is, method). Otherwise, a SecurityException is thrown. For example, if you deny a permission, P, you must revert that permission before you can deny another permission, Q, in the same method.
Use one of the static methods listed in the following table to revert an override.
Method |
Method Action |
|---|---|
Causes all previous overrides for the current frame to be removed and no longer in effect. |
|
Causes any previous Assert for the current frame to be removed and no longer in effect. |
|
Causes any previous Deny for the current frame to be removed and no longer in effect. This method is obsolete in the .NET Framework 4. |
|
Causes any previous PermitOnly for the current frame to be removed and no longer in effect. |
See Also
Reference
Concepts
Writing Secure Class Libraries