Re: SecurityException on GetTempFileName()

"David Thielen" <thielen@xxxxxxxxxxxxx> wrote in message
news:27DAE788-3662-4048-A4A7-8DC11A148127@xxxxxxxxxxxxxxxx
> 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
>
>
> "Nicole Calinoiu" wrote:
>
>> "David Thielen" <thielen@xxxxxxxxxxxxx> wrote in message
>> news:9896BAB7-5E68-41BF-B0A0-5215F8E7F8B0@xxxxxxxxxxxxxxxx
>> > 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
>> the way. <g>
>>
>>
>> > 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)]
>> > [assembly:DnsPermission(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)]
>> > [assembly:PublisherIdentityPermission(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
>> >
>>
>>
>>


.

Relevant Pages

  • Re: Help me to undersand ???
    ... Do you work in a company or as a consultant in security? ... Your assembly may be granted unrestricted permissions under CAS policy, ... request it. ... assembly-level permission attributes can only be used to ...
    (microsoft.public.dotnet.security)
  • Re: Help me to undersand ???
    ... I am actually prpearing my MCSD and i select as next exam .Net security. ... Your assembly may be granted unrestricted permissions under CAS policy, ... request it. ... assembly-level permission attributes can only be used to ...
    (microsoft.public.dotnet.security)
  • Re: Help me to undersand ???
    ... I am actually prpearing my MCSD and i select as next exam .Net security. ... permissions that you do not explicitly request via either a RequestMinimum ... assembly-level permission attributes can only be used to ...
    (microsoft.public.dotnet.security)
  • Re: SecurityException on GetTempFileName()
    ... I am guessing it's the assembly permissions in the client library (which I ... > permission for the demand to pass. ... If any assembly on the call stack lacks ... >> communication DLL does not need any of the above permissions. ...
    (microsoft.public.dotnet.framework)
  • Re: Help me to undersand ???
    ... I work at a developer and architect at a software company, not as a security ... Your assembly may be granted unrestricted permissions under CAS ... request it. ... assembly-level permission attributes can only be used to ...
    (microsoft.public.dotnet.security)
Quantcast