This is a bug in the Equinox http service implementation. Please open a bug against Compendium at https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Equinox
The implementation of the http service is performing a privileged operation as an implementation detail which should not be exposed to the callers of HttpService.registerServlet. Tom |------------> | From: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |Shigekuni Kondo <[email protected]> | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | To: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |OSGi Developer Mail List <[email protected]> | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Date: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |03/23/2011 04:38 AM | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Subject: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |Re[2]: [osgi-dev] Question of HttpService Spec | >--------------------------------------------------------------------------------------------------------------------------------------------------| Hi BJ, Thank you very much for your reply. First of all, let me correct the explanation of condition in my previous mail. > <Condition> > HttpService bundle, BundleA and BundleB are running on > an OSGi framework. > > [BundleA] > It gets "Service B" registered by BundleB, and calls the sampleAPI() > method provided by ServiceB. > > BundleA is given the following Permission; > (org.osgi.framework.PackagePermission "org.osgi.framework" "import") > (org.osgi.framework.PackagePermission "sample" "import") > (org.osgi.framework.ServicePermission "sample.ServiceB" "get") > > [BundleB] > It registers ServiceB. > BundleB create SerlvetB instance and registers ServletB to > HttpService by HttpService#registerServlet() in that thread. Correction --> "When sampleAPI() is called," BundleB create SerlvetB instance and registers ServletB to HttpService by HttpService#registerServlet() in that thread. > > When ServletB is accessed, the privileged operation which requires > the specific Permission(PermissionX) is executed. > Remark that there is no AccessController.doPrivileged() in ServletB's > implementation. > > BundleB is given the AllPermission. The following sentence is described in OSGi Service Compendium spec R4.2 section 102.8. --------------- Servlet and HttpContext objects must use a doPrivileged construct in their implementations when performing privileged operations. --------------- Based on the description in OSGi spec and the above condition, I think that the PermissionX is required for Bundle A when the processing in ServletB is executed, regardless of whether HttpContext object is default or user defined, because there is no AccessController.doPrivileged() in ServletB's implementation (It is supposed behavior '1'). Or, is OSGi spec saying the ServletB's implementation must use doPrivileged() method when the privileged operation which requires PermissionX is executed? > Why is Bundle A on the call stack when Bundle B registers ServletB? And I > have no idea why a getContextClassLoader call is made. This is beyond the > OSGi spec. So it would seem that the HttpService impl from Equinox should > wrap that call is a doPrivileged. The reason is that BundleB create SerlvetB instance and registers ServletB to HttpService when sampleAPI() is called by BundleA. Please find attached the stack trace which is output when the error is occurred. <Note> "test.http.servlet.bundlea" is BundleA "test.http.servlet.bundleb" is BundleB Best Regards, Shigekuni Kondo On Sun, 20 Mar 2011 19:37:15 -0400 BJ Hargrave <[email protected]> wrote: > > From: Shigekuni Kondo <[email protected]> > > > > Hi OSGi Experts > > > > > > I would like to ask about HttpService behavior. > > Let me assume the following example to explain my question. > > > > > > <Condition> > > HttpService bundle, BundleA and BundleB are running on > > an OSGi framework. > > > > [BundleA] > > It gets "Service B" registered by BundleB, and calls the sampleAPI() > > method provided by ServiceB. > > > > BundleA is given the following Permission; > > (org.osgi.framework.PackagePermission "org.osgi.framework" "import") > > (org.osgi.framework.PackagePermission "sample" "import") > > (org.osgi.framework.ServicePermission "sample.ServiceB" "get") > > > > [BundleB] > > It registers ServiceB. > > BundleB create SerlvetB instance and registers ServletB to > > HttpService by HttpService#registerServlet() in that thread. > > > > When ServletB is accessed, the privileged operation which requires > > the specific Permission(PermissionX) is executed. > > Remark that there is no AccessController.doPrivileged() in ServletB's > > implementation. > > > > BundleB is given the AllPermission. > > > > > > <Question> > > In the case, I can suppose following behavior. > > >From the OSGi Spec point of view, Which is proper behavior? > > Or is there other correct behavior? > > > > 1. PermissionX is required for Bundle A when the processing in ServletB > > is executed, regardless of whether HttpContext object is default > > or user defined. > > How is bundle A involved here? If an HTTP request is processed by the > HttpService bundle, it will call the ServletB object. Bundle A is not even > on the call stack for a permission check. Just HttpService bundle and > Bundle B. So unless ServletB does a doPrivileged, both HttpService and > Bundle B will need Permission X. > > > 2. PermissionX is NOT required for Bundle A when the processing in > ServletB > > is executed, regardless of whether HttpContext object is default > > or user defined. > > This seems the proper result. I assume a user defined context is defined > by Bundle B and thus has the same ProtectionDomain as ServletB. > > > 3. PermissionX is required for Bundle A when the processing in ServletB > > is executed in case that HttpContext object is default HttpContext. > > > > My understanding is that '1' in above list is correct by checking OSGi > > Service Compendium spec R4.2 section 102.8. > > > > > > In addition, I implemented above bundles and checked the behavior of > several > > HttpService bundles which are released from Equinox, Felix and > Knopflerfish, > > respectivity. > > > > Result of Equinox: > > Thrown RuntimeException in the registerServlet processing because > > BundleA doesn't have RuntimePermission when > Thread#getContextClassLoader() > > is called. > > Why is Bundle A on the call stack when Bundle B registers ServletB? And I > have no idea why a getContextClassLoader call is made. This is beyond the > OSGi spec. So it would seem that the HttpService impl from Equinox should > wrap that call is a doPrivileged. > > > > > Result of Felix: > > The behavior is '2' in above list. > > > > Result of Knopflerfish: > > The behavior is '2' in above list. > > > > > -- > > BJ Hargrave > Senior Technical Staff Member, IBM > OSGi Fellow and CTO of the OSGi Alliance > [email protected] > > office: +1 386 848 1781 > mobile: +1 386 848 3788 _____________________________________________ Shigekuni Kondo Promotion Project 1 NTT Cyber Solutions Laboratories NIPPON TELEGRAPH AND TELEPHONE CORPORATION 1-1 Hikarinooka Yokosuka Kanagawa 239-0847 Japan TEL:+81-46-859-3444 FAX:+81-46-855-1282 E-mail:[email protected] _____________________________________________ [attachment "Exception.txt" deleted by Thomas Watson/Austin/IBM] _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
<<inline: graycol.gif>>
<<inline: ecblank.gif>>
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
