|
Sponsored Links
Resources
.NET Research Library
Get .NET related white papers, case studies and webcasts
|
Tools
Tools
Tools
|
Messages: 0
Messages: 0
Messages: 0
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
FindAPTC
This sample allows you to find out exactly which assemblies in the .NET Framework class library allow partially trusted callers. I wrote this to point out how infeasible it is today to write locally installed code that doesn't run with full trust. MS plans to make this better in the future, but for now, practically speaking, you will most likely be forced to allow all the managed code on your server to run with full trust. Why care? Well it'd be nice to eventually be able to run each assembly with least permissions - why does my assembly need access to the file system in order to calculate PI to the Nth digit?
Even more practically, it'd be nice for administrators to be able to reduce permissions for local code to require it to be at least verifiably type safe. Doing this today isn't feasible, as this means the code wouldn't have "full trust" and thus wouldn't be able to call into many important assemblies like System.Web (ASP.NET), or System.Management.dll (WMI) for instance.
Running with full trust means that there is no guarantee that the code is type safe. Fully trusted code is allowed to request the SkipVerification security permission, which allows it to bypass verification. Managed C++ apps request this permission, as do C# programs compiled with the /unsafe switch. Don't believe anyone who tells you that "all .NET code is verifiably typesafe", because type safety isn't being enforced today except with mobile code.
Download
|
|
 |
|