Thanks, that helps. I think you are running in a special case - namely, a bundle has certain admin permissions on itself. CONTEXT is one of them:
http://docs.osgi.org/specification/osgi.core/8.0.0/framework.security.html#framework.security.impliedpermissions If I change your example to be getting the bundle context of another bundle (e.g., the system bundle) like this: --- a/caged-impl/src/main/kotlin/com/example/caged/impl/CagedActionImpl.kt +++ b/caged-impl/src/main/kotlin/com/example/caged/impl/CagedActionImpl.kt @@ -42,7 +42,7 @@ class CagedActionImpl : CagedAction { // This should be denied too, but isn't. logger.info("- Requesting BundleContext") - bundle.bundleContext + bundle.bundleContext.getBundle(0).bundleContext logger.info("Completed successfully") } it works as expected. Futhermore, your other, manual, test with creating the admin permission makes a mistake - you can't have it be an admin permission with a filter. It would need to be one created for a specific bundle e.g.: --- a/caged-impl/src/main/kotlin/com/example/caged/impl/CagedActionImpl.kt +++ b/caged-impl/src/main/kotlin/com/example/caged/impl/CagedActionImpl.kt @@ -31,7 +31,7 @@ class CagedActionImpl : CagedAction { System.getSecurityManager()?.also { sm -> // I expect this AdminPermission to be denied, but it isn't. - val admin = AdminPermission("(location=${bundle.location})", CONTEXT) + val admin = AdminPermission(bundle.bundleContext.getBundle(0), CONTEXT) works as expected too. As of debugging - I sometimes find it useful to run with "-Djava.security.debug=all" which will log all permission checks (among other things). Obviously, that is a lot (includes all of the jvm as it is not OSGi specific) but e.g. for the modified test above I get this in the output: access: access denied ("org.osgi.framework.AdminPermission" "(id=0)" "context") java.lang.Exception: Stack trace at java.base/java.lang.Thread.dumpStack(Thread.java:1388) at java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:462) at java.base/java.security.AccessController.checkPermission(AccessController.java:897) at java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:322) at com.example.caged.impl.CagedActionImpl.execute(CagedActionImpl.kt:40) at com.example.caged.testing.AdminPermissionTest.testPermissions(AdminPermissionTest.kt:112) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) <SNIP> access: domain that failed [com.example.caged.impl [20](R 20.0)] regards, Karl On Thu, Feb 3, 2022 at 12:35 PM Chris Rankin <ranki...@gmail.com> wrote: > > Hi, > > I have managed to reproduce the issue in this GitHub repository: > https://github.com/chrisr3/osgi-security.git > > I am hoping this is just a misunderstanding somewhere on my part. > > Cheers, > Chris > > On Wed, 2 Feb 2022 at 17:40, Karl Pauls <karlpa...@gmail.com> wrote: > > > > Sounds strange, do you have something you can share that reproduces the > > problem? > > > > regards, > > > > Karl > > > > On Wed, Feb 2, 2022 at 3:56 PM Chris Rankin <ranki...@gmail.com> wrote: > > > > > > Hi, > > > > > > I am starting to suspect that the "CondtionInfo" aspect is actually > > > working correctly, and that the actual problem is with AdminPermission > > > itself. > > > > > > I have added this line to both a bundle whose location matches > > > "CAGE/*" and one whose location doesn't: > > > > > > System.getSecurityManager().checkPermission(new AdminPermission("*", > > > AdminPermission.CONTEXT)); > > > > > > This check correctly does/does not trigger an AccessControlException, > > > according to who invokes it. > > > > > > However, checking AdminPermission(bundle, AdminPermission.CONTEXT) > > > doesn't trigger an exception in either case. > > > > > > Have I completely misunderstood how the AdminPermission's "name" > > > property works? I can't see how everyone has not noticed a bug in > > > something this crucial?! > > > > > > Cheers, > > > Chris > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > > > For additional commands, e-mail: users-h...@felix.apache.org > > > > > > > > > -- > > Karl Pauls > > karlpa...@gmail.com > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > > For additional commands, e-mail: users-h...@felix.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > For additional commands, e-mail: users-h...@felix.apache.org > -- Karl Pauls karlpa...@gmail.com --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
