Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I wondered how certain .NET hosting providers can safely grant full trust to their customers?

Doesn't this open up everybody who is hosting with that company to potential safety issues? Or is there a way to safely restrict each customer, despite giving full trust, to "their" space without giving them the abiliy to bring down the system or spy on other customers?

share|improve this question

migrated from May 26 '10 at 19:17

This question came from our site for professional and enthusiast programmers.

Without knowing anything about .NET, a Virtual Machine would always be a possible solution :) – Konerak May 26 '10 at 17:42
This is not really programming related, so voting to close. – Oded May 26 '10 at 17:44
I think it is very much programming related. I'm developing a .NET application which I potentially want to place on a shared hoster who grants .NET Full Trust. I need to know about the implications to my application, hence programming related. – Alex May 26 '10 at 18:43
Yeah, I agree... this is totally programming related. The technology is actually named "CODE access security" even :P – Stephen M. Redd May 26 '10 at 19:28

In some ways it does, potentially, open up the possibility of problems from one application from affecting others.

But, full trust is actually pretty safe by default already, especially from external attacks. The biggest risks in full trust scenarios are from the legitimate users who could, possibly, upload and run code that does something stupid. Again though, this is a minor risk in overall practice, which is why you see hosting with full trust at all.

Hosting providers also do a few things besides to further reduce the effects of one errant user's idiocy. Most of the providers do make a few tweaks to the "full trust" defaults to eliminate features that solutions wouldn't actually need anyway. They also tend to run each user's account in separate app pools on the server too.

Also, there were some problems with the default medium trust settings that resulted in full trust being very difficult to achieve with many applications. Microsoft has made some changes to how code access security and trust levels work in 4.0 to address these concerns. I haven't dug into the final details myself yet, but you can find a bit of information on them at these links:

Security Changes in the .NET Framework 4

Code Access Security in ASP.NET 4 Applications

share|improve this answer

The "trust" issue of the .net framework is not related to protecting the server. At least not directly.

The hosting providers are (should) protecting their servers by granting limited user rights to the hosted user. Those rights are granted in the operation system level. The VM or langauge that the user is using is not relevant. From most languages you can access the win32 api or the the posix api and do as much damage as your security permission will allow you.

The scenario that the "trust" model of the .net framework is covering, is not much different than the JavaScript parser that is hosted in your browser is providing. Consider the following: You are writing some game server. And you wont to allow third parties to write extensions for you game. You will run the dll's provided by those third parties on your server. You want to allow them to call your api. but you certenlly don't want to allow them to sniff your disk or database directly. In that case the OS security won't help you because those dll run in your process with your credential. So you load those dll's in restiricted trust. And the .net framework will make sure they are not calling any dangerous api.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.