Other than in partial-trust scenarios --? -Steve B.
Steve Bohlen [email protected] http://blog.unhandled-exceptions.com http://twitter.com/sbohlen On Wed, Nov 28, 2012 at 2:14 PM, Patrick Earl <[email protected]> wrote: > Looks like it causes security errors. :( > > > On Tue, Nov 27, 2012 at 6:28 PM, Alexander I. Zaytsev <[email protected]>wrote: > >> Hi all >> >> It may be a very big breaking change! >> >> Best Regards, Alex >> >> >> 2012/11/28 Patrick Earl <[email protected]> >> >>> This sounds like a better alternative to me... what think others? >>> >>> >>> On Tue, Nov 27, 2012 at 7:16 AM, Fabian Schmied < >>> [email protected]> wrote: >>> >>>> Just a comment: you could use >>>> System.Runtime.Serialization.FormatterServices.GetUninitializedObject >>>> to create an instantiate a type (verifiably) without calling its >>>> constructor. >>>> >>>> On Tuesday, November 27, 2012 9:24:30 AM UTC+1, Richard (gmail) wrote: >>>> >>>>> Hi Patrick, >>>>> >>>>> I made the change to make the generated assemblies pass PeVerify: >>>>> https://nhibernate.jira.com/**browse/NH-2857<https://nhibernate.jira.com/browse/NH-2857> >>>>> >>>>> >>>>> I’d agree with the argument that the (default) constructor that NH >>>>> uses shouldn’t be doing anything unusual, but obviously we can’t enforce >>>>> that. >>>>> >>>>> If there is now a situation that we can get a stack overflow using >>>>> (just) NHibernateUtil.IsInitialized, then that should probably be fixed. >>>>> I’m not so sure about casting the object directly to an IProxy and relying >>>>> on the underlying implementation of Interceptors though – it’s not clear >>>>> to >>>>> me how someone would decide what is acceptable/reasonable external >>>>> behaviour for that. In addition, I think the original Castle proxy would >>>>> have behaved like this too? >>>>> >>>>> Also, if you mark the default constructor as private, then the proxy >>>>> has no choice but to bypass it (and behave the way it did prior to that >>>>> fix). Does that help? >>>>> >>>>> Cheers, >>>>> Richard >>>>> >>>>> >>>>> *From:* Patrick Earl >>>>> *Sent:* Tuesday, November 27, 2012 4:57 AM >>>>> *To:* nhibernate-development >>>>> *Subject:* [nhibernate-development] Calling base constructor in >>>>> proxies >>>>> >>>>> I noticed (due to a stack overflow) that proxies now call their base >>>>> constructor. That behaviour is a little scary to me since proxies are not >>>>> real objects and the real objects might have interaction with the world >>>>> that isn't supposed to happen with proxy objects. I suppose the argument >>>>> could be made that the constructor should not be doing anything remotely >>>>> interesting, but on the other hand, constructors should produce objects >>>>> that don't need additional initialization. >>>>> >>>>> The stack overflow itself was from an interesting combination of >>>>> changes in the latest NH. First, it calls the base constructor. Second, >>>>> the dynamic proxy was changed to call "base.Method()" if the interceptor >>>>> was not set. Since there is no "base.Method()" I assume that it ends up >>>>> calling the same method again, resulting in the mysterious stack overflow. >>>>> >>>>> Basically my code was doing something like >>>>> NHibernateUtil.IsInitialized(**a) and when it went to get the >>>>> HibernateLazyInitializer property it overflowed the stack. I ended up >>>>> fixing this by changing my condition as follows: >>>>> >>>>> a is IProxy && (a as IProxy).Interceptor != null && >>>>> NHibernateUtil.IsInitialized(**a) >>>>> >>>>> Perhaps the code to check for uninitialized proxies inside of >>>>> NHibernateUtil needs to be improved. Perhaps a flag could be present to >>>>> disable calling the base constructor when not needed for a medium trust >>>>> environment. Thoughts on this interesting situation? Has anyone else run >>>>> into problems related to calling the base constructor? >>>>> >>>>> Patrick Earl >>>>> >>>> >>>> On Tuesday, November 27, 2012 9:24:30 AM UTC+1, Richard (gmail) wrote: >>>>> >>>>> Hi Patrick, >>>>> >>>>> I made the change to make the generated assemblies pass PeVerify: >>>>> https://nhibernate.jira.com/**browse/NH-2857<https://nhibernate.jira.com/browse/NH-2857> >>>>> >>>>> I’d agree with the argument that the (default) constructor that NH >>>>> uses shouldn’t be doing anything unusual, but obviously we can’t enforce >>>>> that. >>>>> >>>>> If there is now a situation that we can get a stack overflow using >>>>> (just) NHibernateUtil.IsInitialized, then that should probably be fixed. >>>>> I’m not so sure about casting the object directly to an IProxy and relying >>>>> on the underlying implementation of Interceptors though – it’s not clear >>>>> to >>>>> me how someone would decide what is acceptable/reasonable external >>>>> behaviour for that. In addition, I think the original Castle proxy would >>>>> have behaved like this too? >>>>> >>>>> Also, if you mark the default constructor as private, then the proxy >>>>> has no choice but to bypass it (and behave the way it did prior to that >>>>> fix). Does that help? >>>>> >>>>> Cheers, >>>>> Richard >>>>> >>>>> >>>>> *From:* Patrick Earl >>>>> *Sent:* Tuesday, November 27, 2012 4:57 AM >>>>> *To:* nhibernate-development >>>>> *Subject:* [nhibernate-development] Calling base constructor in >>>>> proxies >>>>> >>>>> I noticed (due to a stack overflow) that proxies now call their base >>>>> constructor. That behaviour is a little scary to me since proxies are not >>>>> real objects and the real objects might have interaction with the world >>>>> that isn't supposed to happen with proxy objects. I suppose the argument >>>>> could be made that the constructor should not be doing anything remotely >>>>> interesting, but on the other hand, constructors should produce objects >>>>> that don't need additional initialization. >>>>> >>>>> The stack overflow itself was from an interesting combination of >>>>> changes in the latest NH. First, it calls the base constructor. Second, >>>>> the dynamic proxy was changed to call "base.Method()" if the interceptor >>>>> was not set. Since there is no "base.Method()" I assume that it ends up >>>>> calling the same method again, resulting in the mysterious stack overflow. >>>>> >>>>> Basically my code was doing something like >>>>> NHibernateUtil.IsInitialized(**a) and when it went to get the >>>>> HibernateLazyInitializer property it overflowed the stack. I ended up >>>>> fixing this by changing my condition as follows: >>>>> >>>>> a is IProxy && (a as IProxy).Interceptor != null && >>>>> NHibernateUtil.IsInitialized(**a) >>>>> >>>>> Perhaps the code to check for uninitialized proxies inside of >>>>> NHibernateUtil needs to be improved. Perhaps a flag could be present to >>>>> disable calling the base constructor when not needed for a medium trust >>>>> environment. Thoughts on this interesting situation? Has anyone else run >>>>> into problems related to calling the base constructor? >>>>> >>>>> Patrick Earl >>>>> >>>> >>> >> >
