> The reason why bundle H capture an ACC at the time a servlet is registered > is that it is written in "102.8.2 Accessing Other Types of Resources" in > the spec: > ------- > Therefore, the Http Service must capture > the AccessControlContext object of the bundle registering resources or a > servlet, and then use the captured AccessControlContext object when > accessing resources returned by the registered HttpContext object. > ------- > > However, the behaivior of BundleH that asserting the captured ACC when > calling the Servlet#service() is a bug. BundleH must asserting the > captured ACC is only for getting when accessing resource URL objects as > "102.8.2". > > Is my understanding correct ?
Yes. Thanks for pointing out 102.8.2. So the ACC must only be used when an HttpContext object is supplied (that is, the default HttpContext is not used) and then only when using a returned URL. So the ACC is not used when calling the servlet or calling the supplied HttpContext. > > BJ> For your question at the end, (b) is not correct and (a) is partially > BJ> correct. Servlet B *must* use doPrivilege to exercise some permission it > BJ> has been granted. > > >From spec point of view, let me clarify: > > - Whether the default HttpContext is used or not, Servlet and > HttpContext objects must use a doPrivileged construct in > their implementations when performing privileged operations. Yes. This is always the safe thing to do. > > - The reason of it is there is no guarantee that the permission is not > granted to the HttpService impl bundle. > > Is it correct ? Correct. If the HttpService impl bundle was granted AllPermission *and* did a doPrivileged before calling the servlet or HttpContext objects, then they would not need to use doPriv. But since the spec does not require that HttpService impl bundles be granted AllPermission or must wrap calls to servlets and HttpContexts in a doPriv, then the servlet and HttpContext must perform the doPriv if necessary. -- 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
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
