Uploaded image for project: 'WildFly'
  1. WildFly
  2. WFLY-15071

Remove permissions from ReactiveMessagingChannelsTestCase

XMLWordPrintable

      The target of this work is my currently unmerged https://github.com/wildfly/wildfly/pull/14475. The test in question currently needs the following permissions:

      .addAsManifestResource(createPermissionsXmlAsset(
              new SecurityPermission("insertProvider"),
              new MBeanServerPermission("createMBeanServer"),
              new MBeanPermission("*", "registerMBean, unregisterMBean"),
              new RuntimePermission("getClassLoader"),
              new RuntimePermission("modifyThread"),
              new RuntimePermission("setContextClassLoader"),
              new FilePermission("<<ALL FILES>>", "read"),
              new SocketPermission("*", "connect, resolve")), "permissions.xml"); 

      Upgrading to SmallRye with https://github.com/smallrye/smallrye-reactive-messaging/pull/1334 trims this down to.

      .addAsManifestResource(createPermissionsXmlAsset(
              new SecurityPermission("insertProvider"),
              new FilePermission("<<ALL FILES>>", "read"),
              new SocketPermission("*", "connect, resolve")), "permissions.xml"); 

      The SocketPermission seems valid since the user may configure the URL of the Kafka broker in their MP config, and might be something we want to lock down.

      The FilePermission mainly seems to be when loading jars from Maven and using service loaders. Although more things blow up, the first instance is in JAX-RS/RestEasy, triggered by a load of the Weld proxy which is in the deployment class loader.

      Similarly the SecurityPermission is in JAX-RS and triggered by a load of a Weld proxy from the deployment class loader. These two last permissions are discussed in https://wildfly.zulipchat.com/#narrow/stream/210028-microprofile/topic/Security.20Manager.20permissions

       

      I am pointing out the deployment class loader, as I just had a refresher in how all this works, and it seems a privileged block is needed after the deployment class is called. Essentially classes loaded from a JBoss Modules module have all permissions, but the deployment ones need permissions explicitly granted.

      When calling sensitive code from somewhere the SM checks that all the individual code sources on the call stack have the permission. If not it fails. A privileged block essentially means that all code AFTER the privileged block needs the permissions, but ignores what happens in the code that was called prior to that in the stack.

       

      The reason why I am mentioning the deployment class loader is that SmallRye Reactive Messaging relies on CDI to bootstrap, so I see the generated proxy classes (i.e. from the deployment classloader) in the stack calling through to the SmallRye classes defined in JBoss Modules. So a privileged block is needed after the deployment classes calling through to SmallRye, i.e. in the SmallRye code.

       EDIT:

      I have updated the class with some comments

      .addAsManifestResource(createPermissionsXmlAsset(
              // These are tracked in https://issues.redhat.com/browse/WFLY-15071 and can be reduced
              // eventually.
              // This one seems valid
              new SocketPermission("*", "connect, resolve"),
              // Really this is only /Users/kabir/.m2/repository/org/jboss/resteasy/resteasy-jaxrs/3.15.1.Final/resteasy-jaxrs-3.15.1.Final.jar
              // I am doing <<ALL FILES>> simply to not have to figure out the maven repository location and version
              // The real fix will be in javax.ws.rs.ext.FactoryFinder.find() which should use a privileged
              // block when loading the services. When it cannot find the RestEasy implementation, it
              // ends up throwing a ClassNotFoundException since it defaults to the GlassFish implementation
              // which should not be used. Behind the scenes (which gets swallowed, it throws an
              // AccessControlException due to the missing file.
              new FilePermission("<<ALL FILES>>", "read"),
              // This needs fixing in RestEasy probably
              new SecurityPermission("insertProvider"),
              // These can be removed once https://github.com/smallrye/smallrye-reactive-messaging/pull/1334
              // has been merged and released.
              new MBeanServerPermission("createMBeanServer"),
              new MBeanPermission("*", "registerMBean, unregisterMBean"),
              new RuntimePermission("getClassLoader"),
              new RuntimePermission("modifyThread"),
              new RuntimePermission("setContextClassLoader")), "permissions.xml"); 

       

       

       

              kkhan1@redhat.com Kabir Khan
              kkhan1@redhat.com Kabir Khan
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: