Please report new issues athttps://github.com/DOCGroup
Created a bugzilla entry to record the problem of collocated invocation with SSLIOP in a separate thread. Thanks to Ravi Kanth <kanth.ravi@wipro.com> to report the problem and provided a testing program to demonstrate the bug. There is a workaround for this problem, i.e., just pass '-ORBCollocation no' to the server. Also if the collocated invocation is in the same thread as the caller, it won't fail. I am attaching a test which still needs some work to make it a fully acceptable DOC regression test( e.g., get rid of all warnings, use ACE_Task to create thread, etc). Since I am having some other higher priority work to do, I'll park the test here at this moment.
Created attachment 764 [details] a regression test a regression test which is close to complete, but still need some work.
relevant mailing list discussion: http://groups.google.com/group/comp.soft-sys.ace/browse_thread/thread/f6f5313754da3d37/607f3c797af7240c?hl=en#607f3c797af7240c
More conversations: Hi Ravi, [kanth.ravi@wipro.com - Tue Mar 27 04:06:06 2007]: > I am facing an issue using TAO SSLIOP. I have already reported > this in "comp.soft-sys.ace" newsgroup requesting for help. Right, I saw your message and noticed you were routed to our support address. > TAO VERSION: 1.4a_p11 Thank you for using the PRF! Also, thank you for the detailed description of the problem. I have a suggestion at the end of your description... > SYNOPSIS: > Using Security, through a separate thread, we are trying to resolve > and narrow own ORB and through the narrowed object, calling a > different IDL method. > > Then, it throws NO_PERMISSION exception. > > DESCRIPTION: > > We are using Naming Service through SSLIOP and we have our own module, > A, which resolves naming service and gets itself registered with > Naming service (with a name, say, "MODULEA") and does ORB->run(). It > also impements an IDL which contains two methods sendMessage() and > callMessage(). > > In sendMessage() method we are creating a separate thread. > > In this thread, through naming context, we are trying to resolve and > narrow "MODULEA" (i.e., trying to resolve and narrow own module). > Through the narrowed object, we are trying to call other IDL method > i.e callMessage(). > > Then, it throws a NO_PERMISSION exception. > > ******namingSvc.conf********* > dynamic SSLIOP_Factory Service_Object * > TAO_SSLIOP:_make_TAO_SSLIOP_Protocol_Factory() "-SSLAuthenticate > SERVER_AND_CLIENT -SSLPrivateKey PEM:/root/certificates/namingKey.pem > - > SSLCertificate PEM:D:/root/certificates/namingCert.pem" > static Resource_Factory "-ORBProtocolFactory SSLIOP_Factory" > > ********moduleA_Svc.conf******* > dynamic SSLIOP_Factory Service_Object * > TAO_SSLIOP:_make_TAO_SSLIOP_Protocol_Factory() "-SSLAuthenticate NONE > - > SSLPrivateKey PEM:/root/certificates/moduleAKey.pem -SSLCertificate > PEM:/root/certificates/moduleACert.pem" > static Resource_Factory "-ORBProtocolFactory SSLIOP_Factory" > > We have working certificates and keys, CA certificate, all generated > through OpenSSL. > > The same scenario works fine without security. > > I understand that a separate SSL context is created for a separate > thread. But I am unable to find out why this context is not being > identified here. > > Also, I notice that if a different module is resolved and narrowed and > an IDL method is called through it, it works fine. The problem occurs > trying with same module. (i.e. resolving and narrowing own ORB of the > IDL and calling a method on it). I think you are experiencing this problem because the call to an object within your own module ("moduleA") is a "collocated" invocation. TAO is able to determine, by examining endpoints, if the target object of an invocation is within the same ORB or within the same address space as the invoking client (i.e., is collocated with the client). If so, and depending upon the settings of certain policies, TAO will bypass certain layers of the normal invocation path to optimize the invocation. Normally (i.e., without security), this optimization is a "good thing." However, I believe the collocation optimization path is incompatible with the use of SSLIOP, because it does not actually traverse the SSLIOP transport layer. It works when you make a normal (remote) invocation (to a "different module," as you put it), because the invocation path goes through the SSLIOP transport layer in that case. You can turn off the collocation optimization feature by using the "-ORBCollocation no" ORB initialization option (which can be passed on the command line). Then, the invocation path will go through the SSLIOP transport layer even if the target object is collocated with the invoking client. Please try turning off the collocation optimization to see if that helps. ----- Hi Steve Totten, Thanks a lot for your mail. The issue got fixed by using the "-ORBCollocation no" option and it is working fine now. I am thankful to you for your prompt reply. Regards Ravi
changed severity
Wed Apr 25 09:40:12 UTC 2007 Johnny Willemsen <jwillemsen@remedy.nl> * orbsvcs/tests/Security/Bug_2908_Regression/*: Integrated regression for bug 2908. Thanks to Ravi Kanth <kanth dot ravi at wipro dot com> for reporting this issue and delivering the regression test.
accept, valid bug
exception comes from TAO::SSLIOP::Server_Invocation_Interceptor::receive_request_service_contexts
mine
Fixed, see https://github.com/DOCGroup/ATCD/pull/138