Known Issues What actions or circumstances cause the problem? The configuration of an empty security manager maximum set leads to AllPermission being used. When admins deliberately configure an empty set they are really trying to establish an empty permission collection to block any deployments that have declared permissions. The default AllPermission that is assigned in this case forbids this scenario and leads to the opposite behavior (i.e. any declared permission is accepted by the subsystem). How does the problem effect the example/archetype/framework? It prevents admins from blocking deployments that have declared security permissions. There might be a policy in place to block these deployments and the current behavior doesn't allow for that. Does a workaround exist and what is it? Admins always have the option of checking if deployments have permissions (in META-INF/permissions.xml) and simply not deploy them instead of relying on the subsystem to perform this check for them. What now happens to the example/archetype/framework when the workaround is used? Deployments that are to be rejected because they require security permissions are not deployed.

1. store the attached reproducer permissions.war to /tmp 2. start WildFly/EAP with the security manager enabled ( ./standalone.sh -secmgr ) 3. configure the permissions maximum-set (only one FilePermission added): ./jboss-cli.sh -c << EOT /subsystem=security-manager/deployment-permissions= default :write-attribute(name=maximum-permissions, value=[{class=java.io.FilePermission, actions=read, name=\ "/-\" }]) reload EOT 4. deploy the reproducer: ./jboss-cli.sh -c "deploy /tmp/permissions.war" The deployment should fail. You can go to http://localhost:8080/permissions/ and check the output.