". Net deep breathing" restricts permission to execute code

In front of several articles, the old week and the big friends chatted with the application domain-related topics, simply let us talk to the end, scholarship should be so, have perseverance.

There is a special overload in the method for creating new application domains in App domain:

 Public Static AppDomain CreateDomain (stringparams strongname[] fulltrustassemblies);

This overload is special, it's close to what we're talking about today, because one of its argument lists is the PermissionSet type, which represents a collection of permissions that, when the application domain is created, restricts the permissions of code executed in the new application domain through this collection of permissions. In the overloads of each CreateDomain method, only this has parameters that set the permission set.

With this overloaded method, you can put the code that you feel you want to restrict permissions to execute in this new application domain, creating a "sandbox". For example, you get a class library A that someone else wrote, but you don't know what this library a does during execution, so you want to limit it when you use this unknown class library, such as not having it read or write to a file, or just allowing it to access certain directories and files.

In order to cut corners, write the Tofu slag program, old Chuan This example, is to do the test code written to the main assembly. It has a class in which there is a method that, after invocation, creates a file in the Documents Library and writes some of the dirty stuff.

     Public classDemo:marshalbyrefobject { Public voidWirtefile () {stringMyDoc =Environment.getfolderpath (Environment.SpecialFolder.MyDocuments); stringFilePath = Path.Combine (MyDoc, guid.newguid () +". txt"); using(FileStream fs =File.Open (FilePath, FileMode.OpenOrCreate, FileAccess.Write, FileShare.Read)) {                byte[] data = Encoding.UTF8.GetBytes ("Selling counterfeit drugs. "); Fs. Write (data,0, data.            Length); }        }    }

Then, create a new application domain, and then execute the class that you just wrote in the new domain. The reason for inheriting the MarshalByRefObject class is that you want to be able to call across application domains and pass by reference.

The call is as follows:

            //Add assembly Credentials//here is to install force, just write the following lines//Actually, you can use AppDomain.CurrentDomain.Evidence directly .Evidence EVD =NewEvidence (); Assembly Currass=assembly.getexecutingassembly (); Hash HSEVD=NewHash (Currass); Evd. Addassemblyevidence<Hash>(HSEVD); //Prepare relevant informationAppDomainSetup Setup =NewAppDomainSetup (); Setup. ApplicationBase=AppDomain.CurrentDomain.SetupInformation.ApplicationBase; //Prepare PermissionsPermissionSet PS =NewPermissionSet (Permissionstate.none); //execution permissions must be, or the code will not be executedSecurityPermission Secps =NewSecurityPermission (securitypermissionflag.execution); Ps.            Addpermission (SECPS); //Create a new domainAppDomain NEWAPPDM = Appdomain.createdomain ("Good", EVD, Setup, PS); //To create a test object instanceDemo d = (demo) newappdm.createinstanceandunwrap (Currass.fullname, $"{nameof (TESTAPP)}. {nameof (Demo)}");            D.writefile (); D=NULL; AppDomain.Unload (NEWAPPDM);

Evidence this thing is more abstract, you can understand that the assembly is used to prove that it is a legitimate identity of some information, such as here, I use the Hash value of the current assembly as proof, because the Demo class is written in the current assembly (just said, in order to cut corners).

Notice that the permission set is the PermissionSet class, which is a container, and you can add a permission declaration to it as needed. In the above code, I added a most basic security permissions--securitypermission, this you have to add, because it is the most basic permissions, if not add, even code can not execute, it is equal to this piece of code is obsolete, with SecurityPermissionFlag Enumeration to describe the underlying permissions that the code should have, which can be combined, execution means that code is allowed to execute, and if you don't even give this permission, simply dismiss the Demo class.

By the way, when new is out of the PermissionSet instance, the constructor will ask for a permissionstate value, and you should set it to None so that the permission will limit the code, and if unrestricted is used, it means no restrictions.

When the Createinstanceandunwrap method is called, the Demo instance is created in the new application domain, but can be marshaled to the current application domain by reference, so it can be called across domains, and the WriteFile method is actually executed in the new application domain.

If you want to allow code access to files and directories, you must add FileIOPermission permissions, but here I do not add, see what happens after the run.

Because I don't give it permission, it can't write to the file.

Now let's change the code to add FileIOPermission permissions to the permission collection before creating the application domain.

            string DocPath = Environment.getfolderpath (Environment.SpecialFolder.MyDocuments);             New FileIOPermission (fileiopermissionaccess.allaccess, docPath);            Ps. Addpermission (fps);

Again, if the execution succeeds, you will find that there is one more file in the Documents library.

All right, that's it for today.

Sample code

". Net deep breathing" restricts permission to execute code