SecurityException on GetTempFileName()

[Guest]

Hi;

This is driving me nuts because it should work. In my AssemblyInfo.cs I have:
[assembly:CLSCompliant(false)]
[assembly:ComVisible(false)]
[assembly:IsolatedStorageFilePermission(SecurityAction.RequestMinimum,
UserQuota=1048576)]
[assembly:SecurityPermission(SecurityAction.RequestMinimum,
UnmanagedCode=true)]
[assembly:FileIOPermission(SecurityAction.RequestMinimum, Unrestricted=true)]
[assembly:SocketPermission(SecurityAction.RequestMinimum,
Unrestricted=true)]
[assemblynsPermission(SecurityAction.RequestMinimum, Unrestricted=true)]
[assembly:EnvironmentPermission(SecurityAction.RequestMinimum, Read="TEMP")]
// note - also tried with no EnvironmentPermission attribute.

But this call:
Environment.GetEnvironmentVariable("TEMP")

Throws this (note it's mscorlib, not my dll):
"Request for the permission of type
System.Security.Permissions.EnvironmentPermission, mscorlib,
Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 failed."

This is a Word Add-in dll (regular, not VSTO).

Any ideas?

thanks - dave

 

[Guest]

Very weird - I can call this in an event handler. It's when I use a
Form.Invoke(delegate) on a network event and then in the delegate I call it
that I have a problem.

Any ideas???? (again, dialog box in a Word Add-in)

 

[Nicole Calinoiu]

What do you mean by a "network event"?

Very weird - I can call this in an event handler. It's when I use a
Form.Invoke(delegate) on a network event and then in the delegate I call
it
that I have a problem.

Any ideas???? (again, dialog box in a Word Add-in)

--
thanks - dave

Hi;

This is driving me nuts because it should work. In my AssemblyInfo.cs I
have:
[assembly:CLSCompliant(false)]
[assembly:ComVisible(false)]
[assembly:IsolatedStorageFilePermission(SecurityAction.RequestMinimum,
UserQuota=1048576)]
[assembly:SecurityPermission(SecurityAction.RequestMinimum,
UnmanagedCode=true)]
[assembly:FileIOPermission(SecurityAction.RequestMinimum,
Unrestricted=true)]
[assembly:SocketPermission(SecurityAction.RequestMinimum,
Unrestricted=true)]
[assemblynsPermission(SecurityAction.RequestMinimum,
Unrestricted=true)]
[assembly:EnvironmentPermission(SecurityAction.RequestMinimum,
Read="TEMP")]
// note - also tried with no EnvironmentPermission attribute.

But this call:
Environment.GetEnvironmentVariable("TEMP")

Throws this (note it's mscorlib, not my dll):
"Request for the permission of type
System.Security.Permissions.EnvironmentPermission, mscorlib,
Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
failed."

This is a Word Add-in dll (regular, not VSTO).

Any ideas?

thanks - dave

 

[Guest]

When I call Socket.BeginSend(...) I pass it a callback method. That method is
called and I do an Invoke() in that method. In the delegate that Invoke
called I get the security exception.

thanks - dave

--

What do you mean by a "network event"?

Very weird - I can call this in an event handler. It's when I use a
Form.Invoke(delegate) on a network event and then in the delegate I call
it
that I have a problem.

Any ideas???? (again, dialog box in a Word Add-in)

--
thanks - dave

Hi;

This is driving me nuts because it should work. In my AssemblyInfo.cs I
have:
[assembly:CLSCompliant(false)]
[assembly:ComVisible(false)]
[assembly:IsolatedStorageFilePermission(SecurityAction.RequestMinimum,
UserQuota=1048576)]
[assembly:SecurityPermission(SecurityAction.RequestMinimum,
UnmanagedCode=true)]
[assembly:FileIOPermission(SecurityAction.RequestMinimum,
Unrestricted=true)]
[assembly:SocketPermission(SecurityAction.RequestMinimum,
Unrestricted=true)]
[assemblynsPermission(SecurityAction.RequestMinimum,
Unrestricted=true)]
[assembly:EnvironmentPermission(SecurityAction.RequestMinimum,
Read="TEMP")]
// note - also tried with no EnvironmentPermission attribute.

But this call:
Environment.GetEnvironmentVariable("TEMP")

Throws this (note it's mscorlib, not my dll):
"Request for the permission of type
System.Security.Permissions.EnvironmentPermission, mscorlib,
Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
failed."

This is a Word Add-in dll (regular, not VSTO).

Any ideas?

thanks - dave

 

[Nicole Calinoiu]

It sounds like one of two possibilities:

1. Some assembly in the resulting call stack does not have the appropriate
EnvironmentPermission, or
2. Some method in the call stack is deliberately constraining permissions.

Unfortunately, my eyes are crossing a bit trying to figure out what your
call stack might actually look like when the invocation fails. Might you be
able to post the full exception details returned from its ToString method?

When I call Socket.BeginSend(...) I pass it a callback method. That method
is
called and I do an Invoke() in that method. In the delegate that Invoke
called I get the security exception.

thanks - dave

--

What do you mean by a "network event"?

Very weird - I can call this in an event handler. It's when I use a
Form.Invoke(delegate) on a network event and then in the delegate I
call
it
that I have a problem.

Any ideas???? (again, dialog box in a Word Add-in)

--
thanks - dave


:

Hi;

This is driving me nuts because it should work. In my AssemblyInfo.cs
I
have:
[assembly:CLSCompliant(false)]
[assembly:ComVisible(false)]
[assembly:IsolatedStorageFilePermission(SecurityAction.RequestMinimum,
UserQuota=1048576)]
[assembly:SecurityPermission(SecurityAction.RequestMinimum,
UnmanagedCode=true)]
[assembly:FileIOPermission(SecurityAction.RequestMinimum,
Unrestricted=true)]
[assembly:SocketPermission(SecurityAction.RequestMinimum,
Unrestricted=true)]
[assemblynsPermission(SecurityAction.RequestMinimum,
Unrestricted=true)]
[assembly:EnvironmentPermission(SecurityAction.RequestMinimum,
Read="TEMP")]
// note - also tried with no EnvironmentPermission attribute.

But this call:
Environment.GetEnvironmentVariable("TEMP")

Throws this (note it's mscorlib, not my dll):
"Request for the permission of type
System.Security.Permissions.EnvironmentPermission, mscorlib,
Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
failed."

This is a Word Add-in dll (regular, not VSTO).

Any ideas?

thanks - dave

 

[Guest]

Here is the ToString (for the call to Process.Start()):
"System.Security.SecurityException: Request for the permission of type
System.Security.Permissions.SecurityPermission, mscorlib, Version=1.0.5000.0,
Culture=neutral, PublicKeyToken=b77a5c561934e089 failed.\r\n at
System.Security.PermissionListSet.CheckDemand(CodeAccessPermission
demand)\r\n at
Microsoft.Win32.NativeMethods.ShellExecuteEx(ShellExecuteInfo info)\r\n at
System.Diagnostics.Process.StartWithShellExecuteEx(ProcessStartInfo
startInfo)\r\n at System.Diagnostics.Process.Start()\r\n at
System.Diagnostics.Process.Start(ProcessStartInfo startInfo)\r\n at
System.Diagnostics.Process.Start(String fileName)\r\n at
WindwardBear.SpawnReport.LaunchReport() in
c:\\src\\autotag\\autotag2003\\spawnreport.cs:line 163"

 

[Guest]

Here is the call stack:

autotag2003.dll!WindwardBear.SpawnReport.LaunchReport() Line 176 C#

autotag2003.dll!WindwardBear.Framework.LaunchReport(string ext = "html") Line 1948 + 0xb bytes C#

autotag2003.dll!WindwardBear.Framework.RunHtml_Click(Microsoft.Office.Core.CommandBarButton
Ctrl = {Microsoft.Office.Core.CommandBarButtonClass}, bool CancelDefault =
false) Line 1906 C#
[<Non-user Code>]

 

[Guest]

And here is the code that creates the dialog box:

SpawnReport dlg = new SpawnReport(this, ext);
dlg.ShowDialog();

So this calls in to windows (the non-user code) which then calls my delegate
as requested by an earlier BeginInvoke.

??? - thanks - dave

 

[Nicole Calinoiu]

This is a different exception than the one you originally described, and it
doesn't appear to involve any delegate invocation. This one is probably due
to your assembly not being granted SecurityPermission\UnmanagedCode. If
you're not sure why this permission is being denied, you can verify the
permissions and code group membership for your assembly by following the
instructions in the "To evaluate an assembly" section at
http://msdn.microsoft.com/library/e...NETFrameworkAdministrationToolMscorcfgmsc.asp.

 

[Guest]

Hello;

It disallows both getting the TEMP environment var (first posting) and
launching a process (prev posting). But I can do both in the code where I
call ShowDialog() to create this dialog box. It's just in the dialog box
event code that it is not allowed.

The method I am in where this occurs was called via BeginInvoke from a
method in the dialog box that is called as a delegate by the Socket class
when a SendAsync() completes.

My assembly security settings are shown in the first message of this thread.
But since I can make these calls where I create the dialog box - I don't see
how it can be settings for my dll.

???

 

[Peter Huang [MSFT]]

Hi

I reviewed the thread and find that there is a similar issue in the
newsgroup below.Now I have replied to you, you may go and take a look.
Subject: SecurityException in dialog
Newsgroups: microsoft.public.office.developer.com.add_ins

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Nicole Calinoiu]

Hello;

It disallows both getting the TEMP environment var (first posting) and
launching a process (prev posting). But I can do both in the code where I
call ShowDialog() to create this dialog box. It's just in the dialog box
event code that it is not allowed.

OK. It just wasn't clear to me that the exception for which you provided
details was in any way related to the previously discussed exception. Since
it's extremely likely that both permissions limitations stem from the same
cause, could we please stick to just one for now?

The method I am in where this occurs was called via BeginInvoke from a
method in the dialog box that is called as a delegate by the Socket class
when a SendAsync() completes.

I think I might need to try to reproduce this. Unfortunately, the setup is
a bit convoluted, and I'm not convinced that I could repro properly based on
the description you've provided. Do you think you might be able to provide
a simple example as described at
http://www.yoda.arachsys.com/csharp/complete.html?

My assembly security settings are shown in the first message of this
thread.

I suspect that you might not understand what RequestMinimum permissions
attributes actually do. They do not cause permissions to be granted to your
assembly. Instead, they act as instructions to the CLR to not load your
assembly if the permissions are not granted under policy. Nevertheless, it
is entirely possible for your code's permissions to be further constrained
at runtime such that it cannot exploit its full permissions despite its
ability to load correctly.

In addition, when a permission is demanded, all assemblies on the call stack
must pass the demand. Therefore, a demand could fail even if your assembly
has the permission since your assembly is not the only one on the call
stack.

But since I can make these calls where I create the dialog box - I don't
see
how it can be settings for my dll.

The problem is not that your assembly is being denied these permissions
under CAS policy. If it were, your assembly would not load due to its
RequestMinimum permission attributes.

 

[Guest]

Note: I cross-posted this in office add-ins too but posted here in case you
see something. I think it may be the security settings in my communication
DLL (see about 2/3 of the way down).

Hi;

The problem here is complex. Here is the call sequence and where I can call
Path.GetTempPath(). This is all in a Word Add-in in C# (not VSTO).

Menu event handler is called – GetTempPath succeeds
Creates dialog box, calls ShowDialog()
Dialog constructor called – GetTempPath succeeds
Dialog.Activated fires – GetTempPath succeeds

At this time I call a dll of mine built in a totally separate solution. This
performs a network call to a server and returns data. This set of events is:
Socket.BeginConnect(endpoint, ConnectCallback, socket);
ConnectCallback called – calls Socket.BeginSend(…,SendCallback,…);
SendCallback called – calls Socket.BeginReceive(…,ReceiveCallback,…);
At each point in the above calls, it calls a delegate in my dialog code to
give the status of the communication. When the receive is complete, the
dialog code calls:
BeginInvoke(new LaunchDelegate(LaunchReport));

And in the method LaunchReport – GetTempPath throws an exception.
Dialog.Closing fires (after the exception which is caught) – GetTempPath()
succeeds.

The call stack is:
autotag2003.dll!WindwardBear.SpawnReport.LaunchReport() Line 156 C#
[<Non-user Code>]
autotag2003.dll!WindwardBear.Framework.LaunchReport(string ext = "html")
Line 2175 + 0xb bytes C#
autotag2003.dll!WindwardBear.Framework.RunHtml_Click(Microsoft.Office.Core.CommandBarButton
Ctrl = {Microsoft.Office.Core.CommandBarButtonClass}, bool CancelDefault =
false) Line 2132 C#
[<Non-user Code>]

Because I am calling BeginInvoke, I am assuming the top <Non-user Code> is
Windows. But it is possible that it is my separate dll. Is there any way to
determine which it is?

If it is that dll, here are the assembly settings for the communications dll:
[assembly:CLSCompliant(true)]
[assembly:ComVisible(false)]
[assembly:SocketPermission(SecurityAction.RequestMinimum,
Unrestricted=true)]
[assemblynsPermission(SecurityAction.RequestMinimum, Unrestricted=true)]
[assembly:IsolatedStorageFilePermission(SecurityAction.RequestOptional,
UserQuota=1048576)]
[assembly:FileIOPermission(SecurityAction.RequestOptional, Unrestricted=true)]
[assembly:SecurityPermission(SecurityAction.RequestRefuse,
UnmanagedCode=true)]
[assembly:EnvironmentPermission(SecurityAction.RequestRefuse)]
[assembly:FileDialogPermission(SecurityAction.RequestRefuse)]
[assemblyublisherIdentityPermission(SecurityAction.RequestRefuse)]
[assembly:ReflectionPermission(SecurityAction.RequestRefuse)]
[assembly:RegistryPermission(SecurityAction.RequestRefuse)]
[assembly:SiteIdentityPermission(SecurityAction.RequestRefuse)]
[assembly:ZoneIdentityPermission(SecurityAction.RequestRefuse)]
[assembly:UIPermission(SecurityAction.RequestRefuse)]

My understanding of these settings is they affect my communications DLL
only. I don’t want to affect any other application that uses the
communication DLL – the intent of these settings is just to say that the
communication DLL does not need any of the above permissions.

The exception (ToString) is:
System.Security.SecurityException: Request for the permission of type
System.Security.Permissions.EnvironmentPermission, mscorlib,
Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 failed.
at System.Security.PermissionListSet.CheckDemand(CodeAccessPermission
demand, PermissionToken permToken)
at System.Security.CodeAccessSecurityEngine.Check(PermissionToken
permToken, CodeAccessPermission demand, StackCrawlMark& stackMark, Int32
checkFrames, Int32 unrestrictedOverride)
at System.Security.CodeAccessSecurityEngine.Check(CodeAccessPermission
cap, StackCrawlMark& stackMark)
at System.Security.CodeAccessPermission.Demand()
at System.IO.Path.GetTempPath()
at WindwardBear.SpawnReport.LaunchReport() in
c:\\src\\autotag\\autotag2003\\spawnreport.cs:line 152"

thanks - dave

 

[Nicole Calinoiu]

Note: I cross-posted this in office add-ins too but posted here in case
you
see something. I think it may be the security settings in my communication
DLL (see about 2/3 of the way down).

Hi;

The problem here is complex.

Very true. That's why I asked for a sample that reproduces the problem.
While you've provided a lot of information in this message, it's still not
what I'd need to reproduce your scenario properly. To be honest, you could
keep describing your setup until the cows come home, and I still wouldn't
know if you had left out some critical detail. This would really be much
easier to resolve if you would build a simple sample from scratch to
demonstrate the problem. Who knows, you might even find a solution along

Because I am calling BeginInvoke, I am assuming the top <Non-user Code> is
Windows. But it is possible that it is my separate dll. Is there any way
to
determine which it is?
http://msdn.microsoft.com/library/en-us/vsdebug/html/_asug_viewing_the_call_stack_for_a_function.asp



If it is that dll, here are the assembly settings for the communications
dll:
[assembly:CLSCompliant(true)]
[assembly:ComVisible(false)]
[assembly:SocketPermission(SecurityAction.RequestMinimum,
Unrestricted=true)]
[assemblynsPermission(SecurityAction.RequestMinimum, Unrestricted=true)]
[assembly:IsolatedStorageFilePermission(SecurityAction.RequestOptional,
UserQuota=1048576)]
[assembly:FileIOPermission(SecurityAction.RequestOptional,
Unrestricted=true)]
[assembly:SecurityPermission(SecurityAction.RequestRefuse,
UnmanagedCode=true)]
[assembly:EnvironmentPermission(SecurityAction.RequestRefuse)]
[assembly:FileDialogPermission(SecurityAction.RequestRefuse)]
[assemblyublisherIdentityPermission(SecurityAction.RequestRefuse)]
[assembly:ReflectionPermission(SecurityAction.RequestRefuse)]
[assembly:RegistryPermission(SecurityAction.RequestRefuse)]
[assembly:SiteIdentityPermission(SecurityAction.RequestRefuse)]
[assembly:ZoneIdentityPermission(SecurityAction.RequestRefuse)]
[assembly:UIPermission(SecurityAction.RequestRefuse)]

My understanding of these settings is they affect my communications DLL
only.

Yes and no. Using these attributes only affects the permission set of the
assembly in which they appear. However, when a demand is made for a
permission at runtime, all code on the call stack must possess that
permission for the demand to pass. If any assembly on the call stack lacks
that permission (even due to permission attributes), the demand will fail
under normal circumstances. It is possible highly privileged code to
override this behaviour by asserting the permission, but assertion is a
potentially dangerous operation since it exposes your code to luring
attacks.

BTW, once you've made at least on RequestOptional, it's no longer necessary
to use RequestRefuse to reject permissions. This is because RequestOptional
essentially acts as an implicit rejection of all other permissions besides
SecurityPermission\Execution and identity permissions. For a more complete
description of how assembly-level permissions attributes work, see
http://blogs.msdn.com/shawnfa/archive/2004/08/30/222918.aspx.

I don't want to affect any other application that uses the
communication DLL - the intent of these settings is just to say that the
communication DLL does not need any of the above permissions.

Even though the permissions limitation can have an effect due to the full
stack walk when a demand is made, that's not necessarily what's happening
here. Delegates are funny beasts and, depending on what the framework code
is doing around their invocation, the call stack doesn't necessarily end up
including the callers you might expect, but the invoking code might still be
limiting permissions in other ways (e.g.: stack walk modifiers like Deny or
PermitOnly).

 

[Guest]

My problem is that a simple sample works. To get this error requires a Word
Add-in that calls my comm library that triggers an event that then triggers
an event in my Add-in the then calls BeginInvoke that then triggers that
event.

So my "simple" sample would be several thousand lines of code and would not
run unless you had the server component installed & running so the client
communication was successful.

I am guessing it's the assembly permissions in the client library (which I
posted) and am going to try that today.

--
thanks - dave

Note: I cross-posted this in office add-ins too but posted here in case
you
see something. I think it may be the security settings in my communication
DLL (see about 2/3 of the way down).

Hi;

The problem here is complex.

Very true. That's why I asked for a sample that reproduces the problem.
While you've provided a lot of information in this message, it's still not
what I'd need to reproduce your scenario properly. To be honest, you could
keep describing your setup until the cows come home, and I still wouldn't
know if you had left out some critical detail. This would really be much
easier to resolve if you would build a simple sample from scratch to
demonstrate the problem. Who knows, you might even find a solution along

Because I am calling BeginInvoke, I am assuming the top <Non-user Code> is
Windows. But it is possible that it is my separate dll. Is there any way
to
determine which it is?
http://msdn.microsoft.com/library/en-us/vsdebug/html/_asug_viewing_the_call_stack_for_a_function.asp



If it is that dll, here are the assembly settings for the communications
dll:
[assembly:CLSCompliant(true)]
[assembly:ComVisible(false)]
[assembly:SocketPermission(SecurityAction.RequestMinimum,
Unrestricted=true)]
[assemblynsPermission(SecurityAction.RequestMinimum, Unrestricted=true)]
[assembly:IsolatedStorageFilePermission(SecurityAction.RequestOptional,
UserQuota=1048576)]
[assembly:FileIOPermission(SecurityAction.RequestOptional,
Unrestricted=true)]
[assembly:SecurityPermission(SecurityAction.RequestRefuse,
UnmanagedCode=true)]
[assembly:EnvironmentPermission(SecurityAction.RequestRefuse)]
[assembly:FileDialogPermission(SecurityAction.RequestRefuse)]
[assemblyublisherIdentityPermission(SecurityAction.RequestRefuse)]
[assembly:ReflectionPermission(SecurityAction.RequestRefuse)]
[assembly:RegistryPermission(SecurityAction.RequestRefuse)]
[assembly:SiteIdentityPermission(SecurityAction.RequestRefuse)]
[assembly:ZoneIdentityPermission(SecurityAction.RequestRefuse)]
[assembly:UIPermission(SecurityAction.RequestRefuse)]

My understanding of these settings is they affect my communications DLL
only.

Yes and no. Using these attributes only affects the permission set of the
assembly in which they appear. However, when a demand is made for a
permission at runtime, all code on the call stack must possess that
permission for the demand to pass. If any assembly on the call stack lacks
that permission (even due to permission attributes), the demand will fail
under normal circumstances. It is possible highly privileged code to
override this behaviour by asserting the permission, but assertion is a
potentially dangerous operation since it exposes your code to luring
attacks.

BTW, once you've made at least on RequestOptional, it's no longer necessary
to use RequestRefuse to reject permissions. This is because RequestOptional
essentially acts as an implicit rejection of all other permissions besides
SecurityPermission\Execution and identity permissions. For a more complete
description of how assembly-level permissions attributes work, see
http://blogs.msdn.com/shawnfa/archive/2004/08/30/222918.aspx.

I don't want to affect any other application that uses the
communication DLL - the intent of these settings is just to say that the
communication DLL does not need any of the above permissions.

Even though the permissions limitation can have an effect due to the full
stack walk when a demand is made, that's not necessarily what's happening
here. Delegates are funny beasts and, depending on what the framework code
is doing around their invocation, the call stack doesn't necessarily end up
including the callers you might expect, but the invoking code might still be
limiting permissions in other ways (e.g.: stack walk modifiers like Deny or
PermitOnly).

The exception (ToString) is:
System.Security.SecurityException: Request for the permission of type
System.Security.Permissions.EnvironmentPermission, mscorlib,
Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
failed.
at System.Security.PermissionListSet.CheckDemand(CodeAccessPermission
demand, PermissionToken permToken)
at System.Security.CodeAccessSecurityEngine.Check(PermissionToken
permToken, CodeAccessPermission demand, StackCrawlMark& stackMark, Int32
checkFrames, Int32 unrestrictedOverride)
at System.Security.CodeAccessSecurityEngine.Check(CodeAccessPermission
cap, StackCrawlMark& stackMark)
at System.Security.CodeAccessPermission.Demand()
at System.IO.Path.GetTempPath()
at WindwardBear.SpawnReport.LaunchReport() in
c:\\src\\autotag\\autotag2003\\spawnreport.cs:line 152"

thanks - dave

 

[Nicole Calinoiu]

My problem is that a simple sample works. To get this error requires a
Word
Add-in that calls my comm library that triggers an event that then
triggers
an event in my Add-in the then calls BeginInvoke that then triggers that
event.

So my "simple" sample would be several thousand lines of code and would
not
run unless you had the server component installed & running so the client
communication was successful.

I'm guessing that you could probably get by with rather less than several
thousand lines of code, but I agree that the simplest repro wouldn't be
"simple" in absolute terms. If it were, I probably wouldn't have bothered
asking you for the sample in the first place... <g>

I am guessing it's the assembly permissions in the client library (which I
posted) and am going to try that today.

Good luck with that. However, as I mentioned before, you might be dealing
with a constrained delegate scenario, in which case altering the permission
set of this assembly won't necessarily help.

--
thanks - dave

Note: I cross-posted this in office add-ins too but posted here in case
you
see something. I think it may be the security settings in my
communication
DLL (see about 2/3 of the way down).

Hi;

The problem here is complex.

Very true. That's why I asked for a sample that reproduces the problem.
While you've provided a lot of information in this message, it's still
not
what I'd need to reproduce your scenario properly. To be honest, you
could
keep describing your setup until the cows come home, and I still wouldn't
know if you had left out some critical detail. This would really be much
easier to resolve if you would build a simple sample from scratch to
demonstrate the problem. Who knows, you might even find a solution along

Because I am calling BeginInvoke, I am assuming the top <Non-user Code>
is
Windows. But it is possible that it is my separate dll. Is there any
way
to
determine which it is?
http://msdn.microsoft.com/library/en-us/vsdebug/html/_asug_viewing_the_call_stack_for_a_function.asp



If it is that dll, here are the assembly settings for the
communications
dll:
[assembly:CLSCompliant(true)]
[assembly:ComVisible(false)]
[assembly:SocketPermission(SecurityAction.RequestMinimum,
Unrestricted=true)]
[assemblynsPermission(SecurityAction.RequestMinimum,
Unrestricted=true)]
[assembly:IsolatedStorageFilePermission(SecurityAction.RequestOptional,
UserQuota=1048576)]
[assembly:FileIOPermission(SecurityAction.RequestOptional,
Unrestricted=true)]
[assembly:SecurityPermission(SecurityAction.RequestRefuse,
UnmanagedCode=true)]
[assembly:EnvironmentPermission(SecurityAction.RequestRefuse)]
[assembly:FileDialogPermission(SecurityAction.RequestRefuse)]
[assemblyublisherIdentityPermission(SecurityAction.RequestRefuse)]
[assembly:ReflectionPermission(SecurityAction.RequestRefuse)]
[assembly:RegistryPermission(SecurityAction.RequestRefuse)]
[assembly:SiteIdentityPermission(SecurityAction.RequestRefuse)]
[assembly:ZoneIdentityPermission(SecurityAction.RequestRefuse)]
[assembly:UIPermission(SecurityAction.RequestRefuse)]

My understanding of these settings is they affect my communications DLL
only.

Yes and no. Using these attributes only affects the permission set of
the
assembly in which they appear. However, when a demand is made for a
permission at runtime, all code on the call stack must possess that
permission for the demand to pass. If any assembly on the call stack
lacks
that permission (even due to permission attributes), the demand will fail
under normal circumstances. It is possible highly privileged code to
override this behaviour by asserting the permission, but assertion is a
potentially dangerous operation since it exposes your code to luring
attacks.

BTW, once you've made at least on RequestOptional, it's no longer
necessary
to use RequestRefuse to reject permissions. This is because
RequestOptional
essentially acts as an implicit rejection of all other permissions
besides
SecurityPermission\Execution and identity permissions. For a more
complete
description of how assembly-level permissions attributes work, see
http://blogs.msdn.com/shawnfa/archive/2004/08/30/222918.aspx.

I don't want to affect any other application that uses the
communication DLL - the intent of these settings is just to say that
the
communication DLL does not need any of the above permissions.

Even though the permissions limitation can have an effect due to the full
stack walk when a demand is made, that's not necessarily what's happening
here. Delegates are funny beasts and, depending on what the framework
code
is doing around their invocation, the call stack doesn't necessarily end
up
including the callers you might expect, but the invoking code might still
be
limiting permissions in other ways (e.g.: stack walk modifiers like Deny
or
PermitOnly).

The exception (ToString) is:
System.Security.SecurityException: Request for the permission of type
System.Security.Permissions.EnvironmentPermission, mscorlib,
Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
failed.
at System.Security.PermissionListSet.CheckDemand(CodeAccessPermission
demand, PermissionToken permToken)
at System.Security.CodeAccessSecurityEngine.Check(PermissionToken
permToken, CodeAccessPermission demand, StackCrawlMark& stackMark,
Int32
checkFrames, Int32 unrestrictedOverride)
at
System.Security.CodeAccessSecurityEngine.Check(CodeAccessPermission
cap, StackCrawlMark& stackMark)
at System.Security.CodeAccessPermission.Demand()
at System.IO.Path.GetTempPath()
at WindwardBear.SpawnReport.LaunchReport() in
c:\\src\\autotag\\autotag2003\\spawnreport.cs:line 152"

thanks - dave