| Groups | Blog | Home |
dotnet security : SecurityException "Request Failed"
using reflection to invoke methods on a type that is in a partially trusted assembly and I get a security exception (Trace at the end of the post). The method that is making the call has Unrestricted reflection permission asserted. Any idea why this fails. I've tried asserting SecurityPermission+UnmanagedCode in addition and that didn't help. The only thing that seems to work PermissionSet(unrestricted). So, what permissions is this call expecting? Any tools that can help me here? Two more questions. Does the invoked method have all the asserted permissions? I need these permissions to invoke the method dynamically, but I don't necessarily want the method to execute with these privileges. How do I assert a FileIOPermission that allows the right to write to the Console? i.e How is the console represented as a file name? Any help is appreciated. Thx, VJ System.Security.SecurityException: Request failed. at System.Reflection.RuntimeMethodInfo.InternalInvoke (Object obj, BindingFlag s invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean i sBinderDefault, Assembly caller, Boolean verifyAccess) at System.Reflection.RuntimeMethodInfo.InternalInvoke (Object obj, BindingFlag s invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean v erifyAccess) at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invoke Attr, Binder binder, Object[] parameters, CultureInfo culture) at System.Reflection.MethodBase.Invoke(Object obj,
[quoted text, click to view]
"VJ" <anonymous@discussions.microsoft.com> wrote in message news:3c0d01c472b9$2a619150$a601280a@phx.gbl... >I have a locally installed (Full trust) assembly that is > using reflection to invoke methods on a type that is in a > partially trusted assembly and I get a security exception > (Trace at the end of the post). > > The method that is making the call has Unrestricted > reflection permission asserted. Any idea why this fails. If the calling assembly has full trust, there should be no need to assert reflection permissions. The most likely reason for the failure is that the callee requires some permission that is not automatically granted to fully trusted code. Did you author the callee code? What's the accessibility level on the classes and methods you're attempting to call? Can you call them successfully without using reflection?
The calling assembly does have full trust. But the call is
part of a stack frame that has the partially trusted assembly higher up in the call sequence . In other words, the method that is asserting the permissions is being called by the partially trusted assembly, and this method in turn is trying to invoke a method of another class in the partially trusted assembly. eg: a() calls b() calls c() Both a() and c() are in the partially trusted assembly. b() is the method that is asserting the permissions. The type and methods being called are all public. VJ [quoted text, click to view] >-----Original Message-----
>"VJ" <anonymous@discussions.microsoft.com> wrote in message >news:3c0d01c472b9$2a619150$a601280a@phx.gbl... >> The method that is making the call has Unrestricted >> reflection permission asserted. Any idea why this fails. > >If the calling assembly has full trust, there should be no need to assert >reflection permissions. The most likely reason for the failure is that the >callee requires some permission that is not automatically granted to fully >trusted code. Did you author the callee code? What's the accessibility >level on the classes and methods you're attempting to call? Can you call >them successfully without using reflection? > > >.
Yes, and yes :(
[quoted text, click to view] >-----Original Message-----
>Do either or both of the following scenarios work? > >1. Call c() from b() without using reflection. >2. Call c() from b() using reflection, but with c() being launched directly >(not via reflection) from other fully trusted code instead of from a(). > > > >"VJ" <anonymous@discussions.microsoft.com> wrote in message >news:44b901c47336$543898c0$a401280a@phx.gbl... >> The calling assembly does have full trust. But the call is >> part of a stack frame that has the partially trusted >> assembly higher up in the call sequence . In other words, >> the method that is asserting the permissions is being >> called by the partially trusted assembly, and this method >> in turn is trying to invoke a method of another class in >> the partially trusted assembly. >> >> eg: >> a() calls b() calls c() >> >> Both a() and c() are in the partially trusted assembly. >> b() is the method that is asserting the permissions. >> >> The type and methods being called are all public. >> >> VJ >> >>>-----Original Message----- >>>"VJ" <anonymous@discussions.microsoft.com> wrote in >> message >>>news:3c0d01c472b9$2a619150$a601280a@phx.gbl... >>>> The method that is making the call has Unrestricted >>>> reflection permission asserted. Any idea why this fails. >>> >>>If the calling assembly has full trust, there should be >> no need to assert >>>reflection permissions. The most likely reason for the >> failure is that the >>>callee requires some permission that is not automatically >> granted to fully >>>trusted code. Did you author the callee code? What's >> the accessibility >>>level on the classes and methods you're attempting to >> call? Can you call >>>them successfully without using reflection? >>> >>> >>>. >>> > > >.
Do either or both of the following scenarios work?
1. Call c() from b() without using reflection. 2. Call c() from b() using reflection, but with c() being launched directly (not via reflection) from other fully trusted code instead of from a(). [quoted text, click to view] "VJ" <anonymous@discussions.microsoft.com> wrote in message news:44b901c47336$543898c0$a401280a@phx.gbl... > The calling assembly does have full trust. But the call is > part of a stack frame that has the partially trusted > assembly higher up in the call sequence . In other words, > the method that is asserting the permissions is being > called by the partially trusted assembly, and this method > in turn is trying to invoke a method of another class in > the partially trusted assembly. > > eg: > a() calls b() calls c() > > Both a() and c() are in the partially trusted assembly. > b() is the method that is asserting the permissions. > > The type and methods being called are all public. > > VJ > >>-----Original Message----- >>"VJ" <anonymous@discussions.microsoft.com> wrote in > message >>news:3c0d01c472b9$2a619150$a601280a@phx.gbl... >>> The method that is making the call has Unrestricted >>> reflection permission asserted. Any idea why this fails. >> >>If the calling assembly has full trust, there should be > no need to assert >>reflection permissions. The most likely reason for the > failure is that the >>callee requires some permission that is not automatically > granted to fully >>trusted code. Did you author the callee code? What's > the accessibility >>level on the classes and methods you're attempting to > call? Can you call >>them successfully without using reflection? >> >> >>. >>
One possibility is that your partially trusted assembly is doing a LinkDemand, which will fail because instead of your code making the call into the
assembly, now Microsoft code is. The Microsoft reflection code won't have much of the same evidence as your code does, so this makes the LinkDemand extremely likely to fail. As for your other questions: [quoted text, click to view] >Does the invoked method have all the asserted permissions Technically no, it doesn't, but it will behave as though it does. The stack walk will hit your assert, and the security demand will pass (assuming there are no denies on the callstack first). [quoted text, click to view] > FileIOPermission to write to the console Currently there are no permissions needed to write to the Console.-Shawn http://blogs.msdn.com/shawnfa -- This posting is provided "AS IS" with no warranties, and confers no rights. Note: For the benefit of the community-at-large, all responses to this message are best directed to the newsgroup/thread from which they originated. -------------------- [quoted text, click to view] >Content-Class: urn:content-classes:message >From: "VJ" <anonymous@discussions.microsoft.com> >Sender: "VJ" <anonymous@discussions.microsoft.com> >Subject: SecurityException "Request Failed" >Date: Sun, 25 Jul 2004 19:35:07 -0700 >Lines: 47 >Message-ID: <3c0d01c472b9$2a619150$a601280a@phx.gbl> >MIME-Version: 1.0 >Content-Type: text/plain; > charset="iso-8859-1" >Content-Transfer-Encoding: 7bit >X-Newsreader: Microsoft CDO for Windows 2000 >X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 >thread-index: AcRyuSphMLUQqtQGSouUk01MFkQu9A== >Newsgroups: microsoft.public.dotnet.security >Path: cpmsftngxa06.phx.gbl >Xref: cpmsftngxa06.phx.gbl microsoft.public.dotnet.security:6951 >NNTP-Posting-Host: tk2msftngxa14.phx.gbl 10.40.1.166 >X-Tomcat-NG: microsoft.public.dotnet.security > >I have a locally installed (Full trust) assembly that is >using reflection to invoke methods on a type that is in a >partially trusted assembly and I get a security exception >(Trace at the end of the post). > >The method that is making the call has Unrestricted >reflection permission asserted. Any idea why this fails. > >I've tried asserting SecurityPermission+UnmanagedCode in >addition and that didn't help. The only thing that seems >to work PermissionSet(unrestricted). So, what permissions >is this call expecting? Any tools that can help me here? > >Two more questions. > >Does the invoked method have all the asserted permissions? >I need these permissions to invoke the method dynamically, >but I don't necessarily want the method to execute with >these privileges. > >How do I assert a FileIOPermission that allows the right >to write to the Console? i.e How is the console >represented as a file name? > >Any help is appreciated. > >Thx, >VJ > > >System.Security.SecurityException: Request failed. > at System.Reflection.RuntimeMethodInfo.InternalInvoke >(Object obj, BindingFlag >s invokeAttr, Binder binder, Object[] parameters, >CultureInfo culture, Boolean i >sBinderDefault, Assembly caller, Boolean verifyAccess) > at System.Reflection.RuntimeMethodInfo.InternalInvokeMethod >(Object obj, BindingFlag >s invokeAttr, Binder binder, Object[] parameters, >CultureInfo culture, Boolean v >erifyAccess) > at System.Reflection.RuntimeMethodInfo.Invoke(Object >obj, BindingFlags invoke >Attr, Binder binder, Object[] parameters, CultureInfo >culture) > at System.Reflection.MethodBase.Invoke(Object obj, >Object[] parameters) >
Unfortunately, I can reproduce the problem just fine, and it definitely runs
counter to the available documentation on the permissions that are supposed to be required for this sort of invocation via reflection. I'll try to play with it a bit more to see if I can narrow down the problem a bit. However, in case it's not possible to make the problem without unrestricted permissions, perhaps it might be best if you could describe what exactly it is you are trying to do. Maybe someone can suggest an alternative that wouldn't require reflection at all... [quoted text, click to view] "VJ" <anonymous@discussions.microsoft.com> wrote in message news:493201c4735d$475349d0$a501280a@phx.gbl... > Yes, and yes :( > >>-----Original Message----- >>Do either or both of the following scenarios work? >> >>1. Call c() from b() without using reflection. >>2. Call c() from b() using reflection, but with c() > being launched directly >>(not via reflection) from other fully trusted code > instead of from a(). >> >> >> >>"VJ" <anonymous@discussions.microsoft.com> wrote in > message >>news:44b901c47336$543898c0$a401280a@phx.gbl... >>> The calling assembly does have full trust. But the call > is >>> part of a stack frame that has the partially trusted >>> assembly higher up in the call sequence . In other > words, >>> the method that is asserting the permissions is being >>> called by the partially trusted assembly, and this > method >>> in turn is trying to invoke a method of another class in >>> the partially trusted assembly. >>> >>> eg: >>> a() calls b() calls c() >>> >>> Both a() and c() are in the partially trusted assembly. >>> b() is the method that is asserting the permissions. >>> >>> The type and methods being called are all public. >>> >>> VJ >>> >>>>-----Original Message----- >>>>"VJ" <anonymous@discussions.microsoft.com> wrote in >>> message >>>>news:3c0d01c472b9$2a619150$a601280a@phx.gbl... >>>>> The method that is making the call has Unrestricted >>>>> reflection permission asserted. Any idea why this > fails. >>>> >>>>If the calling assembly has full trust, there should be >>> no need to assert >>>>reflection permissions. The most likely reason for the >>> failure is that the >>>>callee requires some permission that is not > automatically >>> granted to fully >>>>trusted code. Did you author the callee code? What's >>> the accessibility >>>>level on the classes and methods you're attempting to >>> call? Can you call >>>>them successfully without using reflection? >>>> >>>> >>>>. >>>> >> >> >>. >>
Of course, I found one possible problem during my first bit of fiddling
after my last post... <g> Is your partially trusted assembly strongly named? What I found was that the documented permissions for the reflection methods are sufficient to permit the full chain to complete as expected unless the assembly being invoked via reflection is strongly named, in which case your original exception is seen. If your partially trusted assembly is strongly named, the big remaining question would be what the minimum permission set is for this apparently undocumented case. While it's possible that unrestricted permissions are necessary to invoke a strongly named assembly in this way, it's also possible that only one or two additional permissions are required. However, without documentation, this could mean a lot of trial and error... [quoted text, click to view] "VJ" <anonymous@discussions.microsoft.com> wrote in message news:493201c4735d$475349d0$a501280a@phx.gbl... > Yes, and yes :( > >>-----Original Message----- >>Do either or both of the following scenarios work? >> >>1. Call c() from b() without using reflection. >>2. Call c() from b() using reflection, but with c() > being launched directly >>(not via reflection) from other fully trusted code > instead of from a(). >> >> >> >>"VJ" <anonymous@discussions.microsoft.com> wrote in > message >>news:44b901c47336$543898c0$a401280a@phx.gbl... >>> The calling assembly does have full trust. But the call > is >>> part of a stack frame that has the partially trusted >>> assembly higher up in the call sequence . In other > words, >>> the method that is asserting the permissions is being >>> called by the partially trusted assembly, and this > method >>> in turn is trying to invoke a method of another class in >>> the partially trusted assembly. >>> >>> eg: >>> a() calls b() calls c() >>> >>> Both a() and c() are in the partially trusted assembly. >>> b() is the method that is asserting the permissions. >>> >>> The type and methods being called are all public. >>> >>> VJ >>> >>>>-----Original Message----- >>>>"VJ" <anonymous@discussions.microsoft.com> wrote in >>> message >>>>news:3c0d01c472b9$2a619150$a601280a@phx.gbl... >>>>> The method that is making the call has Unrestricted >>>>> reflection permission asserted. Any idea why this > fails. >>>> >>>>If the calling assembly has full trust, there should be >>> no need to assert >>>>reflection permissions. The most likely reason for the >>> failure is that the >>>>callee requires some permission that is not > automatically >>> granted to fully >>>>trusted code. Did you author the callee code? What's >>> the accessibility >>>>level on the classes and methods you're attempting to >>> call? Can you call >>>>them successfully without using reflection? >>>> >>>> >>>>. >>>> >> >> >>. >>
Thanks for the answers.
[quoted text, click to view] >-----Original Message----- is doing a LinkDemand, which will fail because instead of >One possibility is that your partially trusted assembly your code making the call into the [quoted text, click to view] >assembly, now Microsoft code is. The Microsoft reflection code won't have much of the same evidence as your code does, so this makes the [quoted text, click to view] >LinkDemand extremely likely to fail. I'm afraid not. The code in the PTA (Partially trusted assembly) has no link demands. [quoted text, click to view] > it does. The stack walk will hit your assert, and the >As for your other questions: >>Does the invoked method have all the asserted permissions >Technically no, it doesn't, but it will behave as though security demand will pass (assuming [quoted text, click to view] >there are no denies on the callstack first). Interesting. Do you know this for a fact? This would be a serious security risk. Between the point where the invoke is called (which is Full trust code) and the point where the invoked method in the PTA starts executing, everything in the stack is MS dynamic invocation code. So, there is no opportunity to deny anything. So, since I have to assert (say even the minimum documented ReflectionPermission, although it appears the only set that works is full unrestricted permissions) to call the method, the method i'm invoking will always have the asserted permissions. [quoted text, click to view] > Console.>> FileIOPermission to write to the console >Currently there are no permissions needed to write to the Thanks. I'm not sure I am seeing this behavior, but I'll double check. [quoted text, click to view] > responses to this message are best directed to the >-Shawn >http://blogs.msdn.com/shawnfa > >-- > >This posting is provided "AS IS" with no warranties, and confers no rights. >Note: For the benefit of the community-at-large, all newsgroup/thread from which they [quoted text, click to view] >originated.
>-------------------- >>Content-Class: urn:content-classes:message >>From: "VJ" <anonymous@discussions.microsoft.com> >>Sender: "VJ" <anonymous@discussions.microsoft.com> >>Subject: SecurityException "Request Failed" >>Date: Sun, 25 Jul 2004 19:35:07 -0700 >>Lines: 47 >>Message-ID: <3c0d01c472b9$2a619150$a601280a@phx.gbl> >>MIME-Version: 1.0 >>Content-Type: text/plain; >> charset="iso-8859-1" >>Content-Transfer-Encoding: 7bit >>X-Newsreader: Microsoft CDO for Windows 2000 >>X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 >>thread-index: AcRyuSphMLUQqtQGSouUk01MFkQu9A== >>Newsgroups: microsoft.public.dotnet.security >>Path: cpmsftngxa06.phx.gbl >>Xref: cpmsftngxa06.phx.gbl microsoft.public.dotnet.security:6951 >>NNTP-Posting-Host: tk2msftngxa14.phx.gbl 10.40.1.166 >>X-Tomcat-NG: microsoft.public.dotnet.security >> >>I have a locally installed (Full trust) assembly that is >>using reflection to invoke methods on a type that is in a >>partially trusted assembly and I get a security exception >>(Trace at the end of the post). >> >>The method that is making the call has Unrestricted >>reflection permission asserted. Any idea why this fails. >> >>I've tried asserting SecurityPermission+UnmanagedCode in >>addition and that didn't help. The only thing that seems >>to work PermissionSet(unrestricted). So, what permissions >>is this call expecting? Any tools that can help me here? >> >>Two more questions. >> >>Does the invoked method have all the asserted permissions? >>I need these permissions to invoke the method dynamically, >>but I don't necessarily want the method to execute with >>these privileges. >> >>How do I assert a FileIOPermission that allows the right >>to write to the Console? i.e How is the console >>represented as a file name? >> >>Any help is appreciated. >> >>Thx, >>VJ >> >> >>System.Security.SecurityException: Request failed. >> at System.Reflection.RuntimeMethodInfo.InternalInvoke >>(Object obj, BindingFlag >>s invokeAttr, Binder binder, Object[] parameters, >>CultureInfo culture, Boolean i >>sBinderDefault, Assembly caller, Boolean verifyAccess) >> at System.Reflection.RuntimeMethodInfo.InternalInvokeMethod >>(Object obj, BindingFlag >>s invokeAttr, Binder binder, Object[] parameters, >>CultureInfo culture, Boolean v >>erifyAccess) >> at System.Reflection.RuntimeMethodInfo.Invoke(Object >>obj, BindingFlags invoke >>Attr, Binder binder, Object[] parameters, CultureInfo >>culture) >> at System.Reflection.MethodBase.Invoke(Object obj, >>Object[] parameters) >> > > >.
Thanks for taking the time to reproduce the problem.
First, my Partially trusted assembly(PTA) is strong named. I've tried making my best guesses as to what the permissions needed are, but haven't been able to figure it out. I can say it is definitely a CAS issue, as when I assert full permissions, the call goes through. W/o giving away too much ;) I have a library A that is locally installed and is used by applications that may be PTA in certain scenarios (application is downloaded etc). In the library, I attempt to instantiate classes in the PTA based on some criteria (I walk through the types in the PTA and check for criteria) upon initialization. [quoted text, click to view] >-----Original Message-----
>Unfortunately, I can reproduce the problem just fine, and it definitely runs >counter to the available documentation on the permissions that are supposed >to be required for this sort of invocation via reflection. I'll try to play >with it a bit more to see if I can narrow down the problem a bit. However, >in case it's not possible to make the problem without unrestricted >permissions, perhaps it might be best if you could describe what exactly it >is you are trying to do. Maybe someone can suggest an alternative that >wouldn't require reflection at all... > > > >"VJ" <anonymous@discussions.microsoft.com> wrote in message >news:493201c4735d$475349d0$a501280a@phx.gbl... >> Yes, and yes :( >> >>>-----Original Message----- >>>Do either or both of the following scenarios work? >>> >>>1. Call c() from b() without using reflection. >>>2. Call c() from b() using reflection, but with c() >> being launched directly >>>(not via reflection) from other fully trusted code >> instead of from a(). >>> >>> >>> >>>"VJ" <anonymous@discussions.microsoft.com> wrote in >> message >>>news:44b901c47336$543898c0$a401280a@phx.gbl... >>>> The calling assembly does have full trust. But the call >> is >>>> part of a stack frame that has the partially trusted >>>> assembly higher up in the call sequence . In other >> words, >>>> the method that is asserting the permissions is being >>>> called by the partially trusted assembly, and this >> method >>>> in turn is trying to invoke a method of another class in >>>> the partially trusted assembly. >>>> >>>> eg: >>>> a() calls b() calls c() >>>> >>>> Both a() and c() are in the partially trusted assembly. >>>> b() is the method that is asserting the permissions. >>>> >>>> The type and methods being called are all public. >>>> >>>> VJ >>>> >>>>>-----Original Message----- >>>>>"VJ" <anonymous@discussions.microsoft.com> wrote in >>>> message >>>>>news:3c0d01c472b9$2a619150$a601280a@phx.gbl... >>>>>> The method that is making the call has Unrestricted >>>>>> reflection permission asserted. Any idea why this >> fails. >>>>> >>>>>If the calling assembly has full trust, there should be >>>> no need to assert >>>>>reflection permissions. The most likely reason for the >>>> failure is that the >>>>>callee requires some permission that is not >> automatically >>>> granted to fully >>>>>trusted code. Did you author the callee code? What's >>>> the accessibility >>>>>level on the classes and methods you're attempting to >>>> call? Can you call >>>>>them successfully without using reflection? >>>>> >>>>> >>>>>. >>>>> >>> >>> >>>. >>> > > >.
Is there any reason you couldn't use delegates for this?
[quoted text, click to view] "VJ" <anonymous@discussions.microsoft.com> wrote in message news:75ee01c4765b$6694dd30$a301280a@phx.gbl... > Thanks for taking the time to reproduce the problem. > > First, my Partially trusted assembly(PTA) is strong named. > I've tried making my best guesses as to what the > permissions needed are, but haven't been able to figure it > out. I can say it is definitely a CAS issue, as when I > assert full permissions, the call goes through. > > W/o giving away too much ;) I have a library A that is > locally installed and is used by applications that may be > PTA in certain scenarios (application is downloaded etc). > In the library, I attempt to instantiate classes in the > PTA based on some criteria (I walk through the types in > the PTA and check for criteria) upon initialization. > > >>-----Original Message----- >>Unfortunately, I can reproduce the problem just fine, and > it definitely runs >>counter to the available documentation on the permissions > that are supposed >>to be required for this sort of invocation via > reflection. I'll try to play >>with it a bit more to see if I can narrow down the > problem a bit. However, >>in case it's not possible to make the problem without > unrestricted >>permissions, perhaps it might be best if you could > describe what exactly it >>is you are trying to do. Maybe someone can suggest an > alternative that >>wouldn't require reflection at all... >> >> >> >>"VJ" <anonymous@discussions.microsoft.com> wrote in > message >>news:493201c4735d$475349d0$a501280a@phx.gbl... >>> Yes, and yes :( >>> >>>>-----Original Message----- >>>>Do either or both of the following scenarios work? >>>> >>>>1. Call c() from b() without using reflection. >>>>2. Call c() from b() using reflection, but with c() >>> being launched directly >>>>(not via reflection) from other fully trusted code >>> instead of from a(). >>>> >>>> >>>> >>>>"VJ" <anonymous@discussions.microsoft.com> wrote in >>> message >>>>news:44b901c47336$543898c0$a401280a@phx.gbl... >>>>> The calling assembly does have full trust. But the > call >>> is >>>>> part of a stack frame that has the partially trusted >>>>> assembly higher up in the call sequence . In other >>> words, >>>>> the method that is asserting the permissions is being >>>>> called by the partially trusted assembly, and this >>> method >>>>> in turn is trying to invoke a method of another class > in >>>>> the partially trusted assembly. >>>>> >>>>> eg: >>>>> a() calls b() calls c() >>>>> >>>>> Both a() and c() are in the partially trusted > assembly. >>>>> b() is the method that is asserting the permissions. >>>>> >>>>> The type and methods being called are all public. >>>>> >>>>> VJ >>>>> >>>>>>-----Original Message----- >>>>>>"VJ" <anonymous@discussions.microsoft.com> wrote in >>>>> message >>>>>>news:3c0d01c472b9$2a619150$a601280a@phx.gbl... >>>>>>> The method that is making the call has Unrestricted >>>>>>> reflection permission asserted. Any idea why this >>> fails. >>>>>> >>>>>>If the calling assembly has full trust, there should > be >>>>> no need to assert >>>>>>reflection permissions. The most likely reason for > the >>>>> failure is that the >>>>>>callee requires some permission that is not >>> automatically >>>>> granted to fully >>>>>>trusted code. Did you author the callee code? What's >>>>> the accessibility >>>>>>level on the classes and methods you're attempting to >>>>> call? Can you call >>>>>>them successfully without using reflection? >>>>>> >>>>>> >>>>>>. >>>>>> >>>> >>>> >>>>. >>>> >> >> >>. >>
Something had been nagging at me about this, and I just got my memory jogged
this morning... Your PTA is strongly named, which means that it needs the AllowPartiallyTrustedCallersAttribute to be set in order to avoid FullTrust link demands even though it is not fully trusted itself. Reflection turns link demands into full demands, so the call is failing due to the PTA being present on the stack. To avoid the problem, use AllowPartiallyTrustedCallersAttribute to allow partially trusted callers into your PTA. HTH, Nicole [quoted text, click to view] "VJ" <anonymous@discussions.microsoft.com> wrote in message news:75ee01c4765b$6694dd30$a301280a@phx.gbl... > Thanks for taking the time to reproduce the problem. > > First, my Partially trusted assembly(PTA) is strong named. > I've tried making my best guesses as to what the > permissions needed are, but haven't been able to figure it > out. I can say it is definitely a CAS issue, as when I > assert full permissions, the call goes through. > > W/o giving away too much ;) I have a library A that is > locally installed and is used by applications that may be > PTA in certain scenarios (application is downloaded etc). > In the library, I attempt to instantiate classes in the > PTA based on some criteria (I walk through the types in > the PTA and check for criteria) upon initialization. > > >>-----Original Message----- >>Unfortunately, I can reproduce the problem just fine, and > it definitely runs >>counter to the available documentation on the permissions > that are supposed >>to be required for this sort of invocation via > reflection. I'll try to play >>with it a bit more to see if I can narrow down the > problem a bit. However, >>in case it's not possible to make the problem without > unrestricted >>permissions, perhaps it might be best if you could > describe what exactly it >>is you are trying to do. Maybe someone can suggest an > alternative that >>wouldn't require reflection at all... >> >> >> >>"VJ" <anonymous@discussions.microsoft.com> wrote in > message >>news:493201c4735d$475349d0$a501280a@phx.gbl... >>> Yes, and yes :( >>> >>>>-----Original Message----- >>>>Do either or both of the following scenarios work? >>>> >>>>1. Call c() from b() without using reflection. >>>>2. Call c() from b() using reflection, but with c() >>> being launched directly >>>>(not via reflection) from other fully trusted code >>> instead of from a(). >>>> >>>> >>>> >>>>"VJ" <anonymous@discussions.microsoft.com> wrote in >>> message >>>>news:44b901c47336$543898c0$a401280a@phx.gbl... >>>>> The calling assembly does have full trust. But the > call >>> is >>>>> part of a stack frame that has the partially trusted >>>>> assembly higher up in the call sequence . In other >>> words, >>>>> the method that is asserting the permissions is being >>>>> called by the partially trusted assembly, and this >>> method >>>>> in turn is trying to invoke a method of another class > in >>>>> the partially trusted assembly. >>>>> >>>>> eg: >>>>> a() calls b() calls c() >>>>> >>>>> Both a() and c() are in the partially trusted > assembly. >>>>> b() is the method that is asserting the permissions. >>>>> >>>>> The type and methods being called are all public. >>>>> >>>>> VJ >>>>> >>>>>>-----Original Message----- >>>>>>"VJ" <anonymous@discussions.microsoft.com> wrote in >>>>> message >>>>>>news:3c0d01c472b9$2a619150$a601280a@phx.gbl... >>>>>>> The method that is making the call has Unrestricted >>>>>>> reflection permission asserted. Any idea why this >>> fails. >>>>>> >>>>>>If the calling assembly has full trust, there should > be >>>>> no need to assert >>>>>>reflection permissions. The most likely reason for > the >>>>> failure is that the >>>>>>callee requires some permission that is not >>> automatically >>>>> granted to fully >>>>>>trusted code. Did you author the callee code? What's >>>>> the accessibility >>>>>>level on the classes and methods you're attempting to >>>>> call? Can you call >>>>>>them successfully without using reflection? >>>>>> >>>>>> >>>>>>. >>>>>> >>>> >>>> >>>>. >>>> >> >> >>. >>
Cool! That totally makes sense. I will try it out
immediately and let you know! And thanks, thanks, thanks again for taking the time! The help is totally appreciated. [quoted text, click to view] >-----Original Message-----
>Something had been nagging at me about this, and I just got my memory jogged >this morning... > >Your PTA is strongly named, which means that it needs the >AllowPartiallyTrustedCallersAttribute to be set in order to avoid FullTrust >link demands even though it is not fully trusted itself. Reflection turns >link demands into full demands, so the call is failing due to the PTA being >present on the stack. To avoid the problem, use >AllowPartiallyTrustedCallersAttribute to allow partially trusted callers >into your PTA. > >HTH, >Nicole > > >"VJ" <anonymous@discussions.microsoft.com> wrote in message >news:75ee01c4765b$6694dd30$a301280a@phx.gbl... >> Thanks for taking the time to reproduce the problem. >> >> First, my Partially trusted assembly(PTA) is strong named. >> I've tried making my best guesses as to what the >> permissions needed are, but haven't been able to figure it >> out. I can say it is definitely a CAS issue, as when I >> assert full permissions, the call goes through. >> >> W/o giving away too much ;) I have a library A that is >> locally installed and is used by applications that may be >> PTA in certain scenarios (application is downloaded etc). >> In the library, I attempt to instantiate classes in the >> PTA based on some criteria (I walk through the types in >> the PTA and check for criteria) upon initialization. >> >> >>>-----Original Message----- >>>Unfortunately, I can reproduce the problem just fine, and >> it definitely runs >>>counter to the available documentation on the permissions >> that are supposed >>>to be required for this sort of invocation via >> reflection. I'll try to play >>>with it a bit more to see if I can narrow down the >> problem a bit. However, >>>in case it's not possible to make the problem without >> unrestricted >>>permissions, perhaps it might be best if you could >> describe what exactly it >>>is you are trying to do. Maybe someone can suggest an >> alternative that >>>wouldn't require reflection at all... >>> >>> >>> >>>"VJ" <anonymous@discussions.microsoft.com> wrote in >> message >>>news:493201c4735d$475349d0$a501280a@phx.gbl... >>>> Yes, and yes :( >>>> >>>>>-----Original Message----- >>>>>Do either or both of the following scenarios work? >>>>> >>>>>1. Call c() from b() without using reflection. >>>>>2. Call c() from b() using reflection, but with c() >>>> being launched directly >>>>>(not via reflection) from other fully trusted code >>>> instead of from a(). >>>>> >>>>> >>>>> >>>>>"VJ" <anonymous@discussions.microsoft.com> wrote in >>>> message >>>>>news:44b901c47336$543898c0$a401280a@phx.gbl... >>>>>> The calling assembly does have full trust. But the >> call >>>> is >>>>>> part of a stack frame that has the partially trusted >>>>>> assembly higher up in the call sequence . In other >>>> words, >>>>>> the method that is asserting the permissions is being >>>>>> called by the partially trusted assembly, and this >>>> method >>>>>> in turn is trying to invoke a method of another class >> in >>>>>> the partially trusted assembly. >>>>>> >>>>>> eg: >>>>>> a() calls b() calls c() >>>>>> >>>>>> Both a() and c() are in the partially trusted >> assembly. >>>>>> b() is the method that is asserting the permissions. >>>>>> >>>>>> The type and methods being called are all public. >>>>>> >>>>>> VJ >>>>>> >>>>>>>-----Original Message----- >>>>>>>"VJ" <anonymous@discussions.microsoft.com> wrote in >>>>>> message >>>>>>>news:3c0d01c472b9$2a619150$a601280a@phx.gbl... >>>>>>>> The method that is making the call has Unrestricted >>>>>>>> reflection permission asserted. Any idea why this >>>> fails. >>>>>>> >>>>>>>If the calling assembly has full trust, there should >> be >>>>>> no need to assert >>>>>>>reflection permissions. The most likely reason for >> the >>>>>> failure is that the >>>>>>>callee requires some permission that is not >>>> automatically >>>>>> granted to fully >>>>>>>trusted code. Did you author the callee code? What's >>>>>> the accessibility >>>>>>>level on the classes and methods you're attempting to >>>>>> call? Can you call >>>>>>>them successfully without using reflection? >>>>>>> >>>>>>> >>>>>>>. >>>>>>> >>>>> >>>>> >>>>>. >>>>> >>> >>> >>>. >>> > > >.
Scratch all that I said before :) To answer my own
question, there is no problem here. A security stack walk fails on the first frame that does not have the appropriate permission. So, All stack walks for demands downstream from the dynamically invoked method will fail unless the dynamically invoked method itself has the appropriate permissions. The stack walk will never ever reach as far as the Full trust assembly! So, it doesn't matter that the FT assembly has asserted the permissions. [quoted text, click to view] >>>Does the invoked method have all the asserted permissions >>Technically no, it doesn't, but it will behave as though >it does. The stack walk will hit your assert, and the >security demand will pass (assuming >>there are no denies on the callstack first). > >Interesting. Do you know this for a fact? This would be a >serious security risk. Between the point where the invoke >is called (which is Full trust code) and the point where >the invoked method in the PTA starts executing, everything >in the stack is MS dynamic invocation code. So, there is >no opportunity to deny anything. So, since I have to >assert (say even the minimum documented >ReflectionPermission, although it appears the only set >that works is full unrestricted permissions) to call the >method, the method i'm invoking will always have the >asserted permissions.
It worked!
Thank you, O wise one :) [quoted text, click to view] >-----Original Message-----
>Cool! That totally makes sense. I will try it out >immediately and let you know! And thanks, thanks, thanks >again for taking the time! The help is totally appreciated. > > >>-----Original Message----- >>Something had been nagging at me about this, and I just >got my memory jogged >>this morning... >> >>Your PTA is strongly named, which means that it needs the >>AllowPartiallyTrustedCallersAttribute to be set in order >to avoid FullTrust >>link demands even though it is not fully trusted itself. >Reflection turns >>link demands into full demands, so the call is failing >due to the PTA being >>present on the stack. To avoid the problem, use >>AllowPartiallyTrustedCallersAttribute to allow partially >trusted callers >>into your PTA. >> >>HTH, >>Nicole >> >> >>"VJ" <anonymous@discussions.microsoft.com> wrote in >message >>news:75ee01c4765b$6694dd30$a301280a@phx.gbl... >>> Thanks for taking the time to reproduce the problem. >>> >>> First, my Partially trusted assembly(PTA) is strong >named. >>> I've tried making my best guesses as to what the >>> permissions needed are, but haven't been able to figure >it >>> out. I can say it is definitely a CAS issue, as when I >>> assert full permissions, the call goes through. >>> >>> W/o giving away too much ;) I have a library A that is >>> locally installed and is used by applications that may >be >>> PTA in certain scenarios (application is downloaded >etc). >>> In the library, I attempt to instantiate classes in the >>> PTA based on some criteria (I walk through the types in >>> the PTA and check for criteria) upon initialization. >>> >>> >>>>-----Original Message----- >>>>Unfortunately, I can reproduce the problem just fine, >and >>> it definitely runs >>>>counter to the available documentation on the >permissions >>> that are supposed >>>>to be required for this sort of invocation via >>> reflection. I'll try to play >>>>with it a bit more to see if I can narrow down the >>> problem a bit. However, >>>>in case it's not possible to make the problem without >>> unrestricted >>>>permissions, perhaps it might be best if you could >>> describe what exactly it >>>>is you are trying to do. Maybe someone can suggest an >>> alternative that >>>>wouldn't require reflection at all... >>>> >>>> >>>> >>>>"VJ" <anonymous@discussions.microsoft.com> wrote in >>> message >>>>news:493201c4735d$475349d0$a501280a@phx.gbl... >>>>> Yes, and yes :( >>>>> >>>>>>-----Original Message----- >>>>>>Do either or both of the following scenarios work? >>>>>> >>>>>>1. Call c() from b() without using reflection. >>>>>>2. Call c() from b() using reflection, but with c() >>>>> being launched directly >>>>>>(not via reflection) from other fully trusted code >>>>> instead of from a(). >>>>>> >>>>>> >>>>>> >>>>>>"VJ" <anonymous@discussions.microsoft.com> wrote in >>>>> message >>>>>>news:44b901c47336$543898c0$a401280a@phx.gbl... >>>>>>> The calling assembly does have full trust. But the >>> call >>>>> is >>>>>>> part of a stack frame that has the partially trusted >>>>>>> assembly higher up in the call sequence . In other >>>>> words, >>>>>>> the method that is asserting the permissions is >being >>>>>>> called by the partially trusted assembly, and this >>>>> method >>>>>>> in turn is trying to invoke a method of another >class >>> in >>>>>>> the partially trusted assembly. >>>>>>> >>>>>>> eg: >>>>>>> a() calls b() calls c() >>>>>>> >>>>>>> Both a() and c() are in the partially trusted >>> assembly. >>>>>>> b() is the method that is asserting the permissions. >>>>>>> >>>>>>> The type and methods being called are all public. >>>>>>> >>>>>>> VJ >>>>>>> >>>>>>>>-----Original Message----- >>>>>>>>"VJ" <anonymous@discussions.microsoft.com> wrote in >>>>>>> message >>>>>>>>news:3c0d01c472b9$2a619150$a601280a@phx.gbl... >>>>>>>>> The method that is making the call has >Unrestricted >>>>>>>>> reflection permission asserted. Any idea why this >>>>> fails. >>>>>>>> >>>>>>>>If the calling assembly has full trust, there should >>> be >>>>>>> no need to assert >>>>>>>>reflection permissions. The most likely reason for >>> the >>>>>>> failure is that the >>>>>>>>callee requires some permission that is not >>>>> automatically >>>>>>> granted to fully >>>>>>>>trusted code. Did you author the callee code? >What's >>>>>>> the accessibility >>>>>>>>level on the classes and methods you're attempting >to >>>>>>> call? Can you call >>>>>>>>them successfully without using reflection? >>>>>>>> >>>>>>>> >>>>>>>>. >>>>>>>> >>>>>> >>>>>> >>>>>>. >>>>>> >>>> >>>> >>>>. >>>> >> >> >>. >> >.
Don't see what you're looking for? Try a search.
|
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
| home · blog · groups | Questions? Comments? Contact the dn |