[rabbitmq-discuss] Security Exception in IIS using RabbitMQ Client

[Tim Watson]

On 20 Jul 2012, at 22:56, Tim Watson wrote:

> 
> On 20 Jul 2012, at 19:43, Dave Seltzer <dseltzer at tveyes.com> wrote:
> 
>> Thanks for your help Tim,
>> 
>> It seems like this isn't an issue with actual file IO, but rather Code
>> Security.
>> 
>> I've tried setting <trust level="Full" originUrl="" /> in the web.config,
>> but it doesn't seem to help.
>> 
> 

Ok so according to msdn, FULL is the default level anyway, but these are only partially trusted app domains. Hmn, this will require a bit more configuration I think.

Two things to bare in mind. Firstly, you don't need to set the originUrl to "" and secondly, just setting the appilcation's trust level may not be enough if the server or .NET framework installation have settings (on the host machine) overriding this. I'm assuming you're using ASP.NET 4, which seems to have a slightly different interpretation of the trust level(s) than I remember. Certainly though the central IIS configuration can refuse to give applications (lower down) Full trust, so you need to check with the IIS admin (unless that's you, in which case consult MSDN to figure out where this would be configured).  

Normally I'd also suggest setting a FileIOPermission attribute around the handler that's failing (or inserting a CAS assertion in the code) but I'm still a little unclear what's going on here. My reading of the situation is that as the connection factory instance is initialising, it accesses the DefaultClientProperties property in ConnectionBase, which in turn introspects the assembly itself using reflection. Incidentally, this might be a bit gratuitous, and should certainly assert its own CAS demands - I will file a bug for that. 

Nonetheless, this shouldn't actually prevent you from using the assembly in an ASP.NET application. Interestingly, I would've expected to see a CAS demand for ReflectionPermission (or whatever it's called) rather than FileIOPermission! Please check a few things

- Is the assembly in the GAC? That might not be the panacea it ought to be and a local reference in the bin directory of your webapp might be preferable.
- Is this failing for you locally or only on a remote IIS that you're working with? If you have control over the IIS server, make sure Full trust is available everywhere or at least can be overridden by applications

If you have put the client assembly in the GAC then the calls to Assembly.GetName (that are made in ConnectionBase) will demand FileIOPermission, so that's one to bare in mind.