Application Security and Trust

  • Thread starter Thread starter Nancy Kafer
  • Start date Start date
N

Nancy Kafer

I have a machine that is running the 2.0 version of the .NET Framework. I
have installed a VB .NET application (dll A) on this machine although
instead of installing the files to my local drive I am installing them to a
shared network location. I have another application that calls dll A. When I
try to run the application I get the following message:

See the end of this message for details on invoking

just-in-time (JIT) debugging instead of this dialog box.



************** Exception Text **************

System.Security.SecurityException: Request failed.

at
System.Security.CodeAccessSecurityEngine.ThrowSecurityException(Assembly
asm, PermissionSet granted, PermissionSet refused, RuntimeMethodHandle rmh,
SecurityAction action, Object demand, IPermission permThatFailed)

at System.Security.CodeAccessSecurityEngine.ThrowSecurityException(Object
assemblyOrString, PermissionSet granted, PermissionSet refused,
RuntimeMethodHandle rmh, SecurityAction action, Object demand, IPermission
permThatFailed)

at System.Security.CodeAccessSecurityEngine.CheckSetHelper(PermissionSet
grants, PermissionSet refused, PermissionSet demands, RuntimeMethodHandle
rmh, Object assemblyOrString, SecurityAction action, Boolean throwException)

at
System.Security.CodeAccessSecurityEngine.CheckSetHelper(CompressedStack cs,
PermissionSet grants, PermissionSet refused, PermissionSet demands,
RuntimeMethodHandle rmh, Assembly asm, SecurityAction action)

at Funeral_HomeTEST.FHM1.FHM1_Load(Object sender, EventArgs e)

at System.Windows.Forms.Form.OnLoad(EventArgs e)

at System.Windows.Forms.Form.OnCreateControl()

at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)

at System.Windows.Forms.Control.CreateControl()

at System.Windows.Forms.Control.WmShowWindow(Message& m)

at System.Windows.Forms.Control.WndProc(Message& m)

at System.Windows.Forms.ScrollableControl.WndProc(Message& m)

at System.Windows.Forms.ContainerControl.WndProc(Message& m)

at System.Windows.Forms.Form.WmShowWindow(Message& m)

at System.Windows.Forms.Form.WndProc(Message& m)

at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)

at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)

at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg,
IntPtr wparam, IntPtr lparam)

The action that failed was:

LinkDemand

The type of the first permission that failed was:

System.Security.PermissionSet

The Zone of the assembly that failed was:

Intranet





I have tried several configurations inside the LocalIntranet Zone at the
machine level in my .NET Configuration Wizard as well as making sure that
the application is strongly named and I have set the
AllowPartiallyTrustedConnections attribute in the assemblyinfo.vb file for
this project. Nothing seems to work. The application worked fine with the
1.1 Framework.

Can anyone help with this issue? I am at a loss and am running out of ideas.

Thanks.

Nancy
 
Nancy Kafer said:
I have a machine that is running the 2.0 version of the .NET Framework. I
have installed a VB .NET application (dll A) on this machine although
instead of installing the files to my local drive I am installing them to
a
shared network location. I have another application that calls dll A. When
I
try to run the application I get the following message:
Click to expand...
<snip>

Is the Funeral_HomeTEST.FHM1 form located in your DLL or in the application
that invokes it? Also, could you please post the code for the
Funeral_HomeTEST.FHM1.FHM1_Load method?
I have tried several configurations inside the LocalIntranet Zone at the
machine level in my .NET Configuration Wizard
Click to expand...

Are you sure that you're modifying the CAS policy for version 2.0 of the
framework, not version 1.1? If so, what policy modifications have you
applied?

as well as making sure that
the application is strongly named and I have set the
AllowPartiallyTrustedConnections attribute in the assemblyinfo.vb file for
this project.
Click to expand...

Which one(s)? The DLL, the EXE or both? Also, have you added a
SecurityTransparent or SecurityCritical attribute to the DLL?
 
The Funeral_HomeTEST.FHM1 routine is located inisde the DLL. I can post the
code for the routine although there's a lot of code that happens based on
user responses once the form loads. The error appears and then the form
appears although there's no data on the form. Do you want the Windows
generated code and the Load routine?

How can I tell if I've modified the CAS policy for version 2.0. We have been
making our changes using the Microsoft .NET Framework Configuration under
Control Panel. My bet is that since we're using that we're modifying version
1.1. As far as the policy modifications, we've tried changing the
LocalIntranet Zone to use the following permission sets: FullTrust,
Everything. I also copied the default LocalIntranet permission set and
modified it by adding OLE DB and SQL Client (both with unrestricted access).

We have added the AllowPartiallyTrustedConnections attribute to the DLL
(Funeral_HomeTEST). The calling application is a COBOL program so that
attribute doesn't apply.

Thanks.

Nancy
 
I got my issue resolved. Turns out that I was modifying the 1.1
configuration. Once I ran the caspol command in the 2.0 folder my
application worked.

Thanks for all of your help.

Nancy
 
I have two .NET Framework Configuration Tool icons in my Admin Tools.
One for each version of .Net installed. In any case it tells you the
version in the shortcut name. As for the other stuff, I'm not an
expert in this so take my response with a grain of salt, but if the
COBOL client is running across the network, it is partially trusted
because of its zone. Looks like the VB assembly is calling something
which requires full trust (most .Net assemblies do. . . here is a list
of assemblies that allow partial trust callers:
http://msdn.microsoft.com/library/d...withallowpartiallytrustedcallersattribute.asp)

As far as I can tell, the LinkDemand for fulltrust will fail if
anything in the call stack is partial trust. I just suffered through a
bit of this myself, and was able to interrupt the stack check by doing
a full trust Assert in the intermediate assembly (your VB dll).

[PermissionSet(SecurityAction.Assert, Name = "FullTrust")]

Also had to grant that one full trust privledges with config tool (or
caspol). THis could be dangerous as it opens a potential security
hole, but my guess is that it'd be better than upping your local
intranet zone to full trust. I was able to get around the security
hole by also demanding that my calling assembly be strongname signed,
though in your case i guess that won't work. You could probably create
a custom perm and demand that.
 
Back
Top