 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / Security / February 2006CAS,Stackwalk and code reuse
Hi, I have requirement where I have to elevate CAS just before i make a call to a com+ server. so it's like Myfunction() { Statemen ts to elevate CAS make com+ call Statemen to revert CAS } Instead of duplication the code in all methods I though ..I will extract out that code into two utility function ...and make it kook like this Myfunction() { ElevateCAS(); make com+ call Rewvert(); } This didl not work ...becuase by the time ElevateCAS(); completes it's taken out of stack so ..Rewvert() throws an error.......I think that's how it CAS work .It's evaluated for a stack walk and not for a thread.. YES/NO? Now..what options I have if wnat to reuse the code instead of duplicating in all places where ever I am making the com+ calls. Possible solution.. 1) delegates ...to mimic a single stack walk.....but I hoping there might be a simpler solution 2)Macros..is it possible to write macros in c# 3)Code snipet now in VS 2005..but I am not sure if snipet work in similar way as macros ...in other words ..if i chage the master copy ..my chages should take effect in all places where ever I am using snipet...I don't think snipet work that way...? Any Ideas..what's the best way to do it? Thanks Sidd You will need to make the assertion inline in your method in order for it to be on the correct stack frame. Are you always asserting the same permission(s) or do the asserted permission sets differ between your various methods? > Hi, > I have requirement where I have to elevate CAS just before i make a [quoted text clipped - 43 lines] > Thanks > Sidd thanks. permission do not differ ...if I put every thing in the same finction i.e inline it works...but If i put it in reusable utility functions ..it does not work... And I think reason being call stack would work differently when i put them in utility function. So I know inline code will work ...what I am trying to find out is if there is a way to not write inline code because than I will be duplicating it all over the place...if there is a way to write it in one place and reuse it ? Thanks Sidd No, you can't put the assert or revert into a utility function. However, the permission(s) asserted are the only thing that you are likely to need to change, and you can at least encapsulate those since they do not differ. e.g.: private IStackWalk StandardAssertionPermission() { // Build and return your standard permission to be asserted. } public void SomeMethod() { this.StandardAssertionPermission().Assert(); try { // Any code that needs to run in the assertion context goes here. } finally { CodeAccessPermission.RevertAll(); } // Any post-assertion code goes here. } > thanks. > [quoted text clipped - 10 lines] > Thanks > Sidd Nicole, Couldn't he take the delegate route: delegate void MyDelegate(int i); class Program { public static void ControllerFunction(MyDelegate SomeFunction) { //assert what he needs try{ SomeFunction(); } finally { //revert } } } There's always the possibility that the function can be called without using this controller but.... -jas > Hi, > I have requirement where I have to elevate CAS just before i make a [quoted text clipped - 43 lines] > Thanks > Sidd I left it out of the other message but I assume you'll protect that controller function properly so other people can't use your code as part of a luring attack. jas > Nicole, > [quoted text clipped - 68 lines] > > Thanks > > Sidd That particular delegate approach wouldn't really save work here since it would presumably be necessary to create two methods for each of the current methods: the "real" method and the delegate target. Anonymous methods could help eliminate the need to create the delegate target method under v. 2.0. However, the approach does not work with an anonymous method even though it does with a declared delegate instance. Even if it did, setting up the invocation in the calling method would still be almost as much work as setting up the assert/revert within any given method, particularly if one uses templates or snippets to insert the wrapper code in the first place. As you mentioned in your other message, there's also the issue of attempting to protect the helper method* from unintended use. This would involve not only preventing invocation by potentially malicious callers, but also preventing inappropriate use by naïve callers (who may, for example, enable luring via their code). The latter is quite a bit more difficult than the former, and it's sufficiently high risk that I wouldn't recommend the approach unless there were very compelling reasons. In this particular case, I just don't see either the initial work or the maintenance arguments being all that much of an issue, but ymmv... *BTW, the delegate itself could also use the same protection in order to help prevent scenarios where a delegate instance is passed from potentially harmful code to code that is allowed to invoke the helper method. > Nicole, > [quoted text clipped - 69 lines] >> Thanks >> Sidd thanks to you both. Does impersonation work for a thraed unlike CAS? I mean a code like this will imperosnate for a thread no matter what function sequence it is on the calls stack...and even if that function call is taken out of te stack... windowsImpersonationContext = windowsIdentity.Impersonate(); I think imperosnation works differently than CAS..but wanted to make sure .. Thanks Sidd Yes, although you still need to consider the issue of blocking inappropriate callers. For an impersonation sample that uses delegation in this way, see http://blogs.msdn.com/shawnfa/archive/2005/03/24/401905.aspx. > thanks to you both. > [quoted text clipped - 9 lines] > Thanks > Sidd Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.