Export (0) Print
Expand All

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 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.

Important note Important

In the .NET Framework 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.

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 or PermitOnly. If a caller uses more than one Assert 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 and then Assert.

To replace an override, first call the appropriate revert method (for example, RevertAssert) and then apply the new override.

Note 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 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 and PermitOnly topics.

Note Note

If you perform an override (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.

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.RevertPermitOnly

Causes any previous PermitOnly for the current frame to be removed and no longer in effect.

Show:
© 2014 Microsoft