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:
Upgrading to SmallRye with https://github.com/smallrye/smallrye-reactive-messaging/pull/1334 trims this down to.
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.
I have updated the class with some comments