Re: SecurityException on GetTempFileName()

Tech-Archive recommends: Speed Up your PC by fixing your registry

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


"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: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
    ... only if you use the most restrictive permissions. ... and for which there is demand. ... SELinux is superior to AA for a certain scenario of use cases; ... SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 ...
    (Linux-Kernel)
  • 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 ... >> description of how assembly-level permissions attributes work, ...
    (microsoft.public.dotnet.framework)
  • Re: Why use Demand()?
    ... but you may have a situation where you want to demand permissions ... > I am not sure why one should use the Demand() method? ...
    (microsoft.public.dotnet.security)
  • Re: Cant get unrestricted FileIOPermission to work
    ... it causes a stack walk ... give more permissions to the html page url, ... Demand and seeing if it fails. ... The rule of thumb is that if the app uses any functionality ...
    (microsoft.public.dotnet.security)
  • Re: Checking security at startup?
    ... Firstly I think the strange behavior you are seeing is a result of the way ... the stack walk initiated by the Demand() works. ... see the permissions that your code requires to run. ... > SqlClientPermission(); ...
    (microsoft.public.dotnet.framework.aspnet.security)