[jboss-jira] [JBoss JIRA] (WFLY-4886) jboss-permissions.xml in EAR module allows to grant additional permissions

[ https://issues.jboss.org/browse/WFLY-4886?page=com.atlassian.jira.plugin.... ] Josef Cacek updated WFLY-4886: ------------------------------ Description: 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. More details: - Java EE 7 spec ([JSR 342|https://www.jcp.org/en/jsr/detail?id=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|https://issues.jboss.org/browse/WFLY-400?focusedCommentId=1276158...] 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|https://github.com/wildfly/wildfly/blob/9.0.0.F...] 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._ was: 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. More details: - Java EE 7 spec ([JSR 342|https://www.jcp.org/en/jsr/detail?id=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|https://issues.jboss.org/browse/WFLY-400?focusedCommentId=1276158...] 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|https://github.com/wildfly/wildfly/blob/9.0.0.F...] 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._ -- This message was sent by Atlassian JIRA (v6.4.11#64026)