Introduce a switch in WildFly configuration, which will enable "strict handling of permissions.xml", i.e. it'll allow administrator to disable parsing jboss-permissions.xml in submodules.

If the file META-INF/jboss-permissions.xml is present in a module of EAR application, then the permissions from the jboss-permissions.xml are granted to the module. The EE specification doesn't allow this.

From my PoV it is a security issue, because the application deployer - based on EE specification - is only configuring META-INF/permissions.xml. I.e the deployer is granting a limited set of permissions for the application. If the jboss-permissions.xml in a module grants more permissions then the limit requested by the deployer is not used and the module is granted to do anything.

More details:

• Java EE 7 spec (JSR 342) in section EE.6.2.2.6 says:
  For applications packaged in an .ear file, the declaration of permissions must be at .ear file level. This permission set is applied to all modules and libraries packaged within the .ear file or within its contained modules.

• David says in a comment of WFLY-400:
  We should additionally support a jboss-permissions.xml descriptor with the same schema/syntax. If such a file is present in a top-level deployment, it should take precedence over permissions.xml; if present in a subdeployment, it should replace the permissions for that subdeployment's code source (and any other nested JARs contained therein) only.

• Stefan says in PermissionsParseProcessor JavaDoc:
  As can be noted, the EE spec doesn't allow sub-deployments to override permissions set at the .ear level. We find it a bit too restrictive, so we introduced the META-INF/jboss-permissions.xml descriptor. It uses the same schema as the standard permissions.xml file but, unlike the latter, is always processed and the permissions contained in it override any permissions set by a parent deployment. If a deployment contains both permissions files, jboss-permissions.xml takes precedence over the standard permissions.xml.