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.

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
CodeAccessPermission.RevertAll	Causes all previous overrides for the current frame to be removed and no longer in effect.
CodeAccessPermission.RevertAssert	Causes any previous Assert for the current frame to be removed and no longer in effect.
CodeAccessPermission.RevertDeny	Causes any previous Deny for the current frame to be removed and no longer in effect.
CodeAccessPermission.RevertPermitOnly	Causes any previous PermitOnly for the current frame to be removed and no longer in effect.

See Also

Code Access Security | Writing Secure Class Libraries | Assert Method | Deny Method | PermitOnly Method