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

Reply via email to