Code Access Security is a joke?

I have just read about this article about Code Access Security. It has such an example in it:

using System.Security.Permissions;
public class MyFileAccess开发者_运维技巧or 
{
  public MyFileAccessor(String path, bool readOnly)
  {
    path = MakeFullPath(path); // helper fcn
    FileIOPermissionAccess desiredAccess = readOnly
      ? FileIOPermissionAccess.Read
      : FileIOPermissionAccess.AllAccess;
    FileIOPermission p = new FileIOPermission(desiredAccess, path);
    p.Demand();
    // 
    ••• 
    open the file
   }
   // •••
}

What if I didn't use the FileIOPermissionAccess type and never includ code like p.Demand() in my code at all? In other words, if I want to do something bad, why should I bother to ask permission for that? Isn't it kind of a joke? OR did I take it wrong?

---

Well, yes, the example is a bit of a joke, you'd never write something like this yourself. What's missing is the really important part, the code that // opens the file. A realistic version of it would, say, pinvoke CreateFile().

The point being that Windows doesn't know anything about CAS. So if you provide a utility function like this and you want to enforce the CAS rules then you have to verify that your calling code has the required permission. Of course, this kind of code really only belongs in the .NET framework. Have a look-see at FileStream.Init() and note FileIOPermission being demanded there before the CreateFile call.

---

File access (for example using FileStream) will automatically demand FileIOPermission. And this is so for all standard classes, when they do some action that require permission they will demand it automatically. Look under .NET Framework Security here. So the sample code is useless, no one will explicitly demand file permissions. It is reasonable if you develop some API and your code is signed so that no one can change it.

Read further, here is quote from that article:

Now in the real world, you won't be writing classes like MyFileAccessor to access files. Instead, you'll use system-provided classes such as System.IO.FileStream, which have already been designed to do the appropriate security checks for you. They're often done in the constructor with all of the performance and security implications I discussed earlier.

---

Inside the java.io APIs, you can assure yourself that the checks are being made. If you want to control the access (bypassing a crash before it happens) you must make the appropriate checks PRIOR to the internal checks made by the API calls.

Java code often runs on computers you control, but it also often runs on computers you don't control. Think of Java applets. They should ask permission to access the file system because the author of the program shouldn't be allowed unchecked access to everyone else's file system.

If you need to stop one group of people from doing something malicious, then you need to stop everyone from possibly doing something malicious for the security to be real. Otherwise, the ill-doers will just say that they are part of the trusted unchecked group.

The Java command line executable runs by default with permissions to allow you to touch your own file system. The assumption is that if you launched the program locally, you could have messed up the portions of your file system you had access to anyway. Applets launch with all of these default permissions removed. That way the person browsing the web page where the applet resides must manually grant permissions for a remote program (applet) to touch their file system.

That you see this is proof that there isn't a special back door which bypasses security for some users (or in some conditions).