Further Information Regarding Demand and Assert

You should follow some simple guidelines when building applications requiring the Demand and Assert methods. Your code should assert one or more permissions when it performs a privileged yet safe operation and you don't require callers to have that permission. Note that your code must have the permission being asserted and SecurityPermissionFlag.Assertion, which is the right to assert.

For example, if you assert FileIOPermission, your code must be granted FileIOPermission but any code calling you does not require the permission. If you assert FileIOPermission and your code has not been granted the permission, an exception is raised once a stack-walk is performed.

As mentioned, your code should use the Demand method to demand one or more permissions when you require that callers have the permission. For example, say your application uses e-mail to send notifications to others, and your code has defined a custom permission named EmailAlertPermission. When your code is called, you can demand the permission of all your callers. If any caller does not have EmailAlertPermission, the request fails.

IMPORTANT
A demand does not check the permissions of the code doing the Demand, only its callers. If your Main function has limited permissions, it will still succeed a full trust demand because it has no callers. To check the code's permissions, either call into a function and initiate the Demand there it'll see the caller's permissions or use the SecurityManager.IsGranted method to directly see whether a permission is granted to your assembly (and only your assembly callers may not have permission). This does not mean you can write malicious code in Main and have it work! As soon as the code calls classes that attempt to perform potentially dangerous tasks, they will incur a stack-walk and permission check.

IMPORTANT
For performance reasons, do not demand permissions if you call code that also makes the same demands. Doing so will simply cause unneeded stack-walks. For example, there's no need to demand EnvironmentPermission when calling Environment.GetEnvironmentVariable, because the .NET Framework does this for you.

It is feasible to write code that makes asserts and demands. For example, using the e-mail scenario above, the code that interfaces directly with the e-mail subsystem might demand that all callers have EmailAlertPermission (your custom permission). Then, when it writes the e-mail message to the SMTP port, it might assert SocketPermission. In this scenario, your callers can use your code for sending e-mail, but they do not require the ability to send data to arbitrary ports, which SocketPermission allows.

Where's the UnmanagedCode Permission?

The ability to call unmanaged code is a highly privileged capability. Once you escape the confines of the managed environment, the code can potentially do anything to the computer, depending on the user account's capabilities. So where is the UnmanagedCode permission? It's tucked away inside another permission.

Some capabilities are simple binary decisions, and others are more complex. The ability to call unmanaged code is a binary decision: your code can, or cannot, call into unmanaged code. The ability to access files, governed by the FileIOPermission class, is more complex. Your code might be granted the ability to read from one file and write to another it's not a simple binary decision. Permission to call unmanaged code is determined by various flags on the SecurityPermission class, as shown in the following line:

[SecurityPermission(SecurityAction.Assert,UnmanagedCode=true)]

Finally, you cannot call Permission.Assert twice it will throw an exception. If you want to assert more than one permission, you must create a permission set, add those permissions to the set, and assert the whole set, like this:

try { PermissionSet ps = new PermissionSet(PermissionState.Unrestricted); ps.AddPermission(new FileDialogPermission (FileDialogPermissionAccess.Open)); ps.AddPermission(new FileIOPermission (FileIOPermissionAccess.Read,@"c:\files")); ps.Assert(); } catch (SecurityException e) { // oops! }