Re: Custom security permission exception error message
From: Nicole Calinoiu (calinoiu)
Date: Fri, 7 Oct 2005 10:14:03 -0400
"Marius Groenendijk" <M (underscore) Groenendijk At (VeryWarm) Mail> wrote
in message news:OgCL%23t2wFHA.2132@TK2MSFTNGP15.phx.gbl...
> Hello group!
> We're planning to use strong naming for our app and this does indeed
> work fine *if* the app has been registered for fulltrust (w/ caspol).
It is, in fact, quite possible to use strong naming without requiring an
unrestricted permission grant (full trust). The only case in which it
becomes an issue is when code with a restricted grant attempts to call into
a strongly named assembly since a link demand for unrestricted permissions
will be automatically generated by the CLR. The resulting security
exception can be avoided by applying the
AllowPartiallyTrustedCallersAttribute (APTCA) to your library assembly.
However, if you choose to go this route, you should take care to perform an
appropriate security audit of the target library assemblies since applying
APTCA can open your code to new security risks due to the new class of
> Trouble is if it's not *yet* fully trusted. Then, if the app starts
> it bombs immediately with an *ugly* message which the average end-user
> would not understand or appreciate (WTH does it mean?):
It means that the implicit link demand for full trust generated by the CLR
failed. (And, yes, it's a horribly opaque exception message. <g>)
> An unhandled exception of type 'System.Security.SecurityException'
> occurred in ...
> Common Language Runtime Debugging Services
> Application has generated an exception that could not be handled.
> Click OK to terminate the application.
> Click CANCEL to debug the application.
> During debugging the debugger doesn't even get as far as executing
> a single line of our code - it's mscoree, on loading the app, that
> issues the 'ugly' msg, right?
> 1) What can we do to try/catch this exception so that *we* can issue
> our own 'friendly' msg?
If you don't want to go the APTCA route, you'll need to ensure that you test
for an unrestricted permission grant in your launching executable (which
won't guarantee unrestricted grants across all assemblies of your
application but is at least a start) in code that runs before the JITting of
any code that uses a non-APTCA library (since link demands are tested at
JIT-time). If your own test for an unrestricted permission grant fails, you
can show whatever friendly error message you like to the user.
> 2) What security permissions are required in AssemblyInfo (something
> that FxCop also keeps complaining about).
They're not required, but they are recommended. These are attributes that
declaratively specify what permissions your assembly needs (or doesn't) in
order to run. See
http://blogs.msdn.com/shawnfa/archive/2004/08/30/222918.aspx for a
description of how these work.
> 3) How to ensure that once the app gets past 1) (fulltrust=OK) that
> it gets the required privileges ( unmanaged code, R/W registry
> access, R/W file io, ui, reflection )?
If an assembly receives an unrestricted permission grant, it will pass a
demand for any built-in or custom CAS permission.
> B.t.w. the app uses ADO.NET, JRO *and* JET
If you're using the types from the System.Data.OleDb namespace to connect to
your Jet db, the assembly calling into those types will need to be fully
trusted since they make explicit link demands for full trust. This is
unrelated to the strong naming issue, but it does mean that at least one of
your assemblies would presumably need to be fully trusted. It also
potentially increases your audit burden should you decide to go the APTCA
route since some fairly dangerous things can be done via db calls.
> Looking forward to any replies which'll be greatly appreciated
> Many thanks,