简体   繁体   English

两个捆绑包之间的OSGi doPrivileged调用

[英]OSGi doPrivileged call between two bundles

i have a problem using OSGi. 我在使用OSGi时遇到问题。

What i have: 我有的:

  • 2 simple bundles (Bundle A calls Bundle B) 2个简单的捆绑包(捆绑包A称为捆绑包B)
  • blueprint usage 蓝图用法
  • OSGi security usage OSGi安全性使用
  • both bundles are core bundles with all permissions 这两个捆绑包都是具有所有权限的核心捆绑包
  • third party bundles don't have all permissions, ie the PropertyPermission("bla", "write") will be denied 第三方捆绑软件没有所有权限,即PropertyPermission(“ bla”,“ write”)将被拒绝

So as already mentioned the bundle call is pretty simple. 因此,正如已经提到的,bundle调用非常简单。 Bundle A calls bundle B. The only complicated thing in it is, that the call is a doPrivileged call. 捆绑软件A调用捆绑软件B。其中唯一复杂的事情是,该调用是doPrivileged调用。

Following scenarios/examples: 以下方案/示例:

Set a "bla" property in bundle A without doPrivileged -> fails (ok) 在没有doPrivileged的包A中设置“ bla”属性->失败(确定)

public void foo() {
 System.setProperty("bla", "blubb"); // throws java.security.AccessControlException: access denied ("java.util.PropertyPermission" "bla" "write") -> ok
}

Set a "bla" property in bundle A with doPrivileged -> works (ok) 使用doPrivileged-> works在捆绑软件A中设置“ bla”属性(确定)

public void foo() {
 AccessController.doPrivileged(new PrivilegedExceptionAction<Boolean>() {
    @Override
    public Boolean run()
       throws Exception
    {
       System.setProperty("bla", "blubb"); // sets the bla property without throwing an exception -> ok
       return null;
    }
 });
}

Now trying to set the "bla" property in bundle B using the doPrivileged call of bundle A -> fails (why?) 现在尝试使用捆绑软件A的doPrivileged调用在捆绑软件B中设置“ bla”属性->失败(为什么?)

Bundle A: 套装A:

public void foo() {
 AccessController.doPrivileged(new PrivilegedExceptionAction<Boolean>() {
    @Override
    public Boolean run()
       throws Exception
    {
       // calls Bundle B
       bundleBService.bar();
       return null;
    }
 });
}

Bundle B: 套装B:

public void bar() {
  System.setProperty("bla", "blubb"); // throws java.security.AccessControlException: access denied ("java.util.PropertyPermission" "bla" "write")
}

So why does it fail to set the property in bundle B using a doPrivileged call of bundle A? 那么,为什么不能使用捆绑软件A的doPrivileged调用在捆绑软件B中设置属性? I would expect, that the doPrivileged call would also work here. 我希望doPrivileged调用也可以在这里工作。 Why it doesn't? 为什么不呢? Is it the fault of using blueprint? 是使用蓝图的错吗? And is it possible wo solve this issue without adding the doPrivileged block to the method of bundle B? 并且可以在不将bundleB方法添加doPrivileged块的情况下解决此问题吗?

Update: Here is the StackTrace: 更新:这是StackTrace:

java.security.AccessControlException: access denied ("java.util.PropertyPermission" "bla" "write")
    at java.security.AccessControlContext.checkPermission(AccessControlContext.java:372)
    at java.security.AccessController.checkPermission(AccessController.java:559)
    at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
    at java.lang.System.setProperty(System.java:782)
    at barpkg.BundleB.bar(BundleB.java:35)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at org.apache.aries.proxy.impl.ProxyHandler$1.invoke(ProxyHandler.java:54)
    at org.apache.aries.proxy.impl.ProxyHandler.invoke(ProxyHandler.java:119)
    at com.sun.proxy.$Proxy111.bar(Unknown Source)
    at foopkg.BundleA$1.run(BundleA.java:73)
    at foopkg.BundleA$1.run(BundleA.java:65)
    at java.security.AccessController.doPrivileged(Native Method)
    at foopkg.BundleA.foo(BundleA.java:65)
    at testpkg.PrivilegedTest.testDoPrivileged(PrivilegedTest.java:135)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
    at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
    at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
    at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
    at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
    at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
    at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
    at org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChild(ContainerTestRunner.java:67)
    at org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChild(ContainerTestRunner.java:37)
    at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
    at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
    at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
    at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
    at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
    at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
    at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
    at org.junit.runner.JUnitCore.run(JUnitCore.java:138)
    at org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.invokeViaJUnit(JUnitProbeInvoker.java:111)
    at org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.findAndInvoke(JUnitProbeInvoker.java:84)
    at org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.call(JUnitProbeInvoker.java:72)
    at org.ops4j.pax.exam.glassfish.GlassFishTestContainer.call(GlassFishTestContainer.java:271)
    at org.ops4j.pax.exam.spi.reactors.SingletonStagedReactor.invoke(SingletonStagedReactor.java:113)
    at org.ops4j.pax.exam.spi.reactors.PerSuiteStagedReactor.invoke(PerSuiteStagedReactor.java:47)
    at org.ops4j.pax.exam.junit.PaxExam$2.evaluate(PaxExam.java:294)
    at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
    at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
    at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
    at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
    at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
    at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
    at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
    at org.ops4j.pax.exam.junit.PaxExam.run(PaxExam.java:111)
    at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:242)
    at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:137)
    at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
    at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
    at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
    at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
    at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)

I'd guess, this lines could be the troublemakers: 我猜这行可能是麻烦制造者:

at org.apache.aries.proxy.impl.ProxyHandler$1.invoke(ProxyHandler.java:54)
at org.apache.aries.proxy.impl.ProxyHandler.invoke(ProxyHandler.java:119)
at com.sun.proxy.$Proxy111.bar(Unknown Source)

I'll try to do this call without using blueprint too see, what happens. 我将尝试不使用蓝图进行此调用,也将发生什么。 But if blueprint is the problem, can i somehow handle it without replacing it? 但是,如果蓝图是问题所在,我可以以某种方式处理它而不更换它吗?

Thank you 谢谢

Ok it works now, using the aries blueprint framework as well. 好的,现在也可以使用aries蓝图框架了。

I've signed the aries blueprint, proxy and utils jars manually (so they are core bundles as well) to see if this would solve the problem. 我已经手动签名了白羊星座蓝图,代理和utils jar(所以它们也是核心包),以查看这是否可以解决问题。 Worked fine. 很好

I'll now create a maven module, where i'll put all the blueprint bundles i need. 现在,我将创建一个Maven模块,在其中放置所需的所有蓝图包。 So i can sign this bundle and don't need to sign each jar separately and also just have one bundle i'll need to deploy. 因此,我可以签名此捆绑包,而不必分别签名每个jar,也只需部署一个捆绑包即可。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM