Go ahead and open a bug. -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance hargr...@us.ibm.com
office: +1 386 848 1781 mobile: +1 386 848 3788 From: Ikuo Yamasaki <yamasaki.i...@lab.ntt.co.jp> To: OSGi Developer Mail List <osgi-dev@mail.osgi.org> Date: 2011/03/27 18:31 Subject: Re: [osgi-dev] Question of HttpService Spec Sent by: osgi-dev-boun...@mail.osgi.org Hi BJ, On Fri, 25 Mar 2011 14:33:55 -0400 BJ Hargrave <hargr...@us.ibm.com> wrote: BJ> > The reason why bundle H capture an ACC at the time a servlet is BJ> registered BJ> > is that it is written in "102.8.2 Accessing Other Types of Resources" in BJ> > the spec: BJ> > ------- BJ> > Therefore, the Http Service must capture BJ> > the AccessControlContext object of the bundle registering resources or a BJ> > servlet, and then use the captured AccessControlContext object when BJ> > accessing resources returned by the registered HttpContext object. BJ> > ------- BJ> > BJ> > However, the behaivior of BundleH that asserting the captured ACC when BJ> > calling the Servlet#service() is a bug. BundleH must asserting the BJ> > captured ACC is only for getting when accessing resource URL objects as BJ> > "102.8.2". BJ> > BJ> > Is my understanding correct ? BJ> BJ> Yes. Thanks for pointing out 102.8.2. So the ACC must only be used when an BJ> HttpContext object is supplied (that is, the default HttpContext is not BJ> used) and then only when using a returned URL. So the ACC is not used when BJ> calling the servlet or calling the supplied HttpContext. I got it. BJ> > BJ> For your question at the end, (b) is not correct and (a) is BJ> partially BJ> > BJ> correct. Servlet B *must* use doPrivilege to exercise some BJ> permission it BJ> > BJ> has been granted. BJ> > BJ> > >From spec point of view, let me clarify: BJ> > BJ> > - Whether the default HttpContext is used or not, Servlet and BJ> > HttpContext objects must use a doPrivileged construct in BJ> > their implementations when performing privileged operations. BJ> BJ> Yes. This is always the safe thing to do. I got it. BJ> > - The reason of it is there is no guarantee that the permission is not BJ> > granted to the HttpService impl bundle. BJ> > BJ> > Is it correct ? BJ> BJ> Correct. If the HttpService impl bundle was granted AllPermission *and* BJ> did a doPrivileged before calling the servlet or HttpContext objects, then BJ> they would not need to use doPriv. But since the spec does not require BJ> that HttpService impl bundles be granted AllPermission or must wrap calls BJ> to servlets and HttpContexts in a doPriv, then the servlet and HttpContext BJ> must perform the doPriv if necessary. I got it. All are cleared ! Thank you very much ! Now I have a proposal for the spec clarification: ------- [Spec Version 1.2] 102.8.1 Accessing Resources in Bundles 102.8.2 Accessing Other Types of Resources The last sentences of the section "The Http Service must only use the captured AccessControlContext when accessing resource URL objects. Servlet and HttpContext objects must use a doPrivileged construct in their implementations when performing privileged operations." [Proposal] 102.8.1 Accessing Resources in Bundles by Default 102.8.2 Accessing Other Types of Resources The last sentences of the section should be shortened. "The Http Service must only use the captured AccessControlContext when accessing resource URL objects." New section "102.8.3 Servlet and HttpContext objects This specification does not require that the Http Service is granted AllPermission or must wrap calls to Servlet and HttpContext objects in a doPrivileged. Therefore, Servlet and HttpContext objects must use a doPrivileged construct in their implementations when performing privileged operations." ------- What do you think ? (I will post a bug if agreed) Best regards, ======= Ikuo YAMASAKI _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
