Thanks, I didn't realise that there were implied permissions here, and that list explains a lot :-).
Curiously, the Javadocs for AdminPermission clearly state that it does support filter conditions: https://docs.osgi.org/javadoc/osgi.core/8.0.0/ The name of this permission is a filter expression. The filter gives access to the following attributes: signer - A Distinguished Name chain used to sign a bundle. Wildcards in a DN are not matched according to the filter string rules, but according to the rules defined for a DN chain. location - The location of a bundle. id - The bundle ID of the designated bundle. name - The symbolic name of a bundle. Filter attribute names are processed in a case sensitive manner. The AdminPermission(Bundle, String) constructor just creates a filter of "(id=<bundleId>)". Thanks again, Cheers, Chris On Thu, 3 Feb 2022 at 15:50, Karl Pauls <karlpa...@gmail.com> wrote: > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
